svn commit: samba r3737 - in branches/SAMBA_4_0/source: auth build/pidl build/smb_build lib lib/dcom lib/dcom/common lib/registry lib/registry/common lib/registry/reg_backend_dir lib/registry/reg_backend_gconf lib/registry/reg_backend_ldb lib/registry/reg_backend_nt4 lib/registry/reg_backend_rpc lib/registry/reg_backend_w95 lib/tdb libcli/auth librpc/rpc ntvfs ntvfs/cifs ntvfs/ipc ntvfs/nbench ntvfs/posix ntvfs/print ntvfs/simple ntvfs/unixuid rpc_server rpc_server/dcom rpc_server/remote smbd

[Jelmer Vernooij]

Hi Tridge, Metze,

Most of the changes I have been making to the build system are due to
realization that there really shouldn't be much difference between 
subsystems, modules and libraries at build level. They all three: 

- Are collections of functions spread over multiple source/object files
- Have dependencies on other subsystems/modules/libraries
- Have zero or more init functions that need to be called when 
  the module/subsystem/library in question is used.

Binaries in Samba consist of one or more source/object files and use one or 
more modules/subsystems/libraries (let's call them "buildparts").

buildparts can be built in three different ways:

- as collections of object files. Dependency checking and making sure
  an object isn't included more then once is done at build level. IMHO 
  this method should only be used on systems that don't have support
  for libraries

- as static libraries (.a files). Dependency checking is done at build
  level. Basically just a bunch of .o files put together in an
  archive.

- as shared libraries (.so files):
  The linker takes care of dependency resolving (very useful!). These shared 
  libraries can then be either directly linked to the executable or loaded 
  dynamically. Because the module can be linked against the buildparts it uses 
  the linker can take care of resolving unknown symbols by loading the 
  necessary libraries (in that case no need for lazy resolving). We 
  could also have a "has_function("functionname")" function that uses dlsym(NULL,
  "functionname") to check whether "functionname" is available in the
  current program. This way we won't need to register subsystems.

The problem with the init functions that have to be called is
currently solved by generating a list of init functions that is called
by a binary at start-up. This should be kept in use for older
compilers. Newer compilers support the "constructor" attribute that
allows you to mark functions that have to be run before main() is
started. The constructor functions will be called when the library
they're in is loaded, so they'll work for both static libraries,
single object files and dynamically loaded libraries (whether they're
loaded at start-time or by dlopen() doesn't matter). Using the
constructor attribute will allow us to not have to fiddle with
recompiling .o files when the list of buildparts for a binary changes
and it will allow using the samba libraries by external developers
without the need for them to call a whole bunch of init functions.

I hope the story above is understable :-) If I haven't explained
something clearly, let me know.

I'm currently working on (optionally) supporting the __attribute__ ((constructor)).

Cheers,

	Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20041117/5be7931d/attachment.bin