CI: Consider using more AC_REPLACE_FUNCS()
#2830
Labels
CI
Entries related to continuous integration infrastructure (historically also recipes like Makefiles)
packaging
portability
We want NUT to build and run everywhere possible
refactor/fightwarn
PR or issue proposal to improve code maintainability without functional changes, or to fix warnings
Milestone
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:
configure.ac
in theAC_REPLACE_FUNCS()
method, causing autotools to generate the needed goals for missing code, and are listed asLTLIBOBJS
macro in that build circumstanceMakefile.am
explicitly, as a pattern likeThis 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 undercommon/
) 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 fromnut_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).The text was updated successfully, but these errors were encountered: