Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: Consider using more AC_REPLACE_FUNCS() #2830

Open
jimklimov opened this issue Mar 2, 2025 · 0 comments
Open

CI: Consider using more AC_REPLACE_FUNCS() #2830

jimklimov opened this issue Mar 2, 2025 · 0 comments
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

Comments

@jimklimov
Copy link
Member

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).

@jimklimov jimklimov added 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 labels Mar 2, 2025
@jimklimov jimklimov added this to the 2.8.4 milestone Mar 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant