-
-
Notifications
You must be signed in to change notification settings - Fork 404
Description
NUT sources include a number of fallback implementations of certain methods that not all target platforms provide on their own.
Ways to integrate those differ:
- a few are listed in
configure.acin theAC_REPLACE_FUNCS()method, causing autotools to generate the needed goals for missing code, and are listed asLTLIBOBJSmacro in that build circumstance - many cases are listed in our
Makefile.amexplicitly, as a pattern like
if !HAVE_SOME_METHOD
something_SOURCES += some_method.c
endif !HAVE_SOME_METHOD
- possibly other tricks are also used (primarily in test code optionally including C files like headers, but that may be or not be not too interesting for this clean-up)
This issue is about investigating more about this, and perhaps simplify recipes where we needlessly re-invented a wheel we are already using elsewhere.
From work done in #2825/#2828 we know that LTLIBOBJS should be used carefully, as they are tacked into our helper libraries (mostly under common/) and it is very possible to end up including two libraries with competing (albeit identical) copies of the object code, or a library and object explicitly (when building a library).
It may make sense to have a further helper library made of only LTLIBOBJS (and maybe some dummy object so it is never empty) that all others can depend on, ensuring a single implementation as far as linker is concerned. This may be (or not be) coupled with #2097 to provide the strings from nut_version.h as that "dummy object".
Maybe all other Makefiles have to be updated, so that library is linked into final programs and published libraries (static/shared) explicitly and on same level as other libcommon*.la helpers, and not through them (complicating the dependency and rebuild tree, and possibly re-introducing those linker conflicts).