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
signature.asc
Description: Digital signature