1
0
mirror of https://github.com/samba-team/samba.git synced 2025-02-09 09:57:48 +03:00

6 Commits

Author SHA1 Message Date
Rusty Russell
f3862b9171 ccan: we're subsystems, not a library.
Don't expose a libccan.so; it would produce clashes if someone else
does the same thing.  Unfortunately, if we just change it from a
SAMBA_LIBRARY to a SAMBA_SUBSYSTEM, it doesn't create a static library
as we'd like, but links all the object files in.  This means we get
many duplicates (eg. everyone gets a copy of tally, even though only
ntdb wants it).

So, the solution is twofold:
1) Make the ccan modules separate.
2) Make the ccan modules SAMBA_SUBSYSTEMs not SAMBA_LIBRARYs so we don't
   build shared libraries which we can't share.
3) Make the places which uses ccan explicit.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Autobuild-User(master): Rusty Russell <rusty@rustcorp.com.au>
Autobuild-Date(master): Fri Jun 29 06:22:44 CEST 2012 on sn-devel-104
2012-06-29 06:22:44 +02:00
Rusty Russell
6244f668a3 TDB2: make SAMBA use tdb1 again for the moment.
Otherwise the following surgery will break the SAMBA build and testsuite.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-06-19 05:38:05 +02:00
Andrew Bartlett
d271bf8dc2 lib/tdb_compat: Do not define BUILD_TDB2 if we are not building tdb2
The simple fact that this was defined at all, even to false, caused some
of the tdb2 build code to run.

Andrew Bartlett
2012-04-11 16:00:38 +02:00
Rusty Russell
985e83ef52 tdb2: tie it into build process if --enable-tdb2-breaks-compat
This is simplistic.  We need to support making TDB2 a standalone library,
but for now, we simply built it in-tree.

Once we have tdb1 compatibility in tdb2, we can rename this option to
--enable-tdb2.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2011-06-20 11:18:36 +02:00
Rusty Russell
0e4c358e27 tdb_compat.h: divert every tdb build and includes to tdb_compat
We change all the headers and wscript files to use tdb_compat; this
means we have one place to decide whether to use TDB1 or TDB2.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2011-06-20 11:18:34 +02:00
Rusty Russell
61bf43f5d1 lib/tdb_compat: header for tdb1 vs tdb2.
TDB2's API is slightly different from TDB1.  In particular, all functions
return 0 (TDB_SUCCESS) or a negative error number, rather than -1 or tdb_null
and storing the error in tdb_error() (though TDB2 does that as well).

The simplest fix is to replace all the different functions with a wrapper,
and that is done here.

Compatibility functions:

tdb_null: not used as an error return, so not defined by tdb2.
tdb_fetch_compat: TDB1-style data-returning tdb_fetch.
tdb_firstkey_compat: TDB1-style data-returning tdb_firstkey
tdb_nextkey_compat: TDB1-style data-returning tdb_nextkey, with
	TDB2-style free of old key.
tdb_errorstr_compat: TDB1-style tdb_errorstr() which takes TDB instead of ecode.
TDB_CONTEXT: TDB1-style typedef for struct tdb_context.
tdb_open_compat: Simplified open routine which takes log function, sets
	TDB_ALLOW_NESTING as Samba expects, and adds TDB_CLEAR_IF_FIRST support.

Things defined away in TDB2 wrappers:

tdb_traverse_read: TDB2's tdb_traverse only uses read-locks anyway.
tdb_reopen/tdb_reopen_all: TDB2 detects this error itself.
TDB_INCOMPATIBLE_HASH: TDB2 uses the Jenkins hash already.
TDB_VOLATILE: TDB2 shouldn't have freelist scaling issues.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2011-06-20 11:18:34 +02:00