Document ideal configure.ac structure #2341
Conversation
| ## | ||
|
|
||
| # | ||
| # The layout of this file is intended to be modular with |
There was a problem hiding this comment.
It is not clear to me what "modular layout" implies in this context. Please drop that phrase or rephrase to clarify.
| # 2. Toolchain detection | ||
| # | ||
| # 3. Build Environment detection | ||
| # | ||
| # 4. Library detection | ||
| # | ||
| # 5. Feature detection |
There was a problem hiding this comment.
This is the primary change request.
The difference/scope of these items is unclear to me. For example, I expect "build environment" to include "toolchain" (listed above) and "library" presence (listed below). These items are further detailed down below, but those details do not help enough to address this concern and raise additional difference/dependency/scope red flags.
If we want to sort ./configure items, then let's start with what non-obvious rules or principles/ideas we want that order to enforce (instead of starting with a specific list that reflects some rules and ideas unknown to PR readers). In other words, propose the comparison function rather than the result of sorting with a comparison function unknown to the reader...
Does autoconf documentation offer any relevant advice?
| m4_include([acinclude/ax_cxx_compile_stdcxx.m4]) | ||
| m4_include([acinclude/win32-sspi.m4]) | ||
|
|
||
| dnl BUG: auto-tools are not supposed to change user (C/CPP/CXX/LD)FLAGS variables. |
There was a problem hiding this comment.
This code does not change those user variables, and our configure code is not auto-tools, so the BUG comment feels misleading or misplaced.
N.B. AX_CXX_COMPILE_STDCXX() (a part of "auto-tools") does change these variables. We use that macro.
Please use XXX instead of BUG.
| dnl BUG: auto-tools are not supposed to change user (C/CPP/CXX/LD)FLAGS variables. | |
| dnl XXX: Do not change and, hence, do not save user-controlled variables. |
| m4_include([acinclude/win32-sspi.m4]) | ||
|
|
||
| dnl BUG: auto-tools are not supposed to change user (C/CPP/CXX/LD)FLAGS variables. | ||
| dnl TODO: set AM_*FLAGS as-needed instead |
There was a problem hiding this comment.
In some cases, instead of using AM_*FLAGS, we should remove our code that changes those user-controlled variables to implement unnecessary environment-specific workarounds (e.g., mips-sgi-irix6 hacks).
| dnl TODO: set AM_*FLAGS as-needed instead | |
| dnl TODO: Remove the corresponding code or refactor it to set AM_*FLAGS where still warranted. |
| # Identify any special parameters need to run the tools correctly. | ||
| # For example; "rm" vs "rm -f", "ar" vs "ar r", "grep -E" vs "egrep", or "-std=17" |
There was a problem hiding this comment.
But these "special parameters" may depend on "build environment" that is detected later on. Even a tool itself may be environment-specific.
There was a problem hiding this comment.
My concept for these at present is that this Toolchain section detects the mandatory program names and flags.
The user should not be casually setting things (can via environment, but should not).
The later Environment section has a lot of overlap, but all things in there are essentially "optional" and may be altered by the user easily with --enable/--with controls.
| # All tests in later sections should be able to include "compat/" | ||
| # files and use their definitions. |
There was a problem hiding this comment.
We should not use compat/ sources in ./configure checks because that would imply that compat/ sources cannot reliably/safely use ./configure results. I hope such use is unnecessary. I suggest studying a specific example that does, in your opinion, require such use.
There was a problem hiding this comment.
My reason for this is to avoid duplicating the autoconf checks logic in both the AC test and compat/ files. We have repeatedly had portability issues with the two locations getting out of sync.
| # Which libraries are available will determine which features | ||
| # can be enabled later. |
There was a problem hiding this comment.
I doubt we should segregate --with-foo from --enable-bar. Both can be treated as "features", and there is often no need for default-enabled library checks if a certain feature is disabled (and vice versa).
There was a problem hiding this comment.
I have segregated with libraries first because many libraries are shared between multiple features. Also, it makes more sense to produce the "cannot enable feature" error message when checking the --enable than when checking the library after already having enabled the feature build.
Both can be treated as "features"
Per autoconf documentation;
- section 15.2
--withis for external software packages (libraries or programs). - section 15.3
--enableis for optional features of the software being built.
2 participants
No description provided.