Skip to content

CI: Consider using more AC_REPLACE_FUNCS() #2830

Open
@jimklimov

Description

@jimklimov

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.ac in the AC_REPLACE_FUNCS() method, causing autotools to generate the needed goals for missing code, and are listed as LTLIBOBJS macro in that build circumstance
  • many cases are listed in our Makefile.am explicitly, 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    CIEntries related to continuous integration infrastructure (historically also recipes like Makefiles)packagingportabilityWe want NUT to build and run everywhere possiblerefactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warnings

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions