Jonas Termansen wrote:
> To recap, my primary requests are:
>
> 1) Categorizing gnulib into three parts (replacement functions for when
> they don't exist, workarounds for bugs, and utility functions).
>
> 2) Making it possible to disable the gnulib bug replacements with a
> configure command line option.
>
> 3) Defaulting to assume the best when cross-compiling to unknown systems.
Now that 3) is implemented, I don't see the utility of 2). If someone is
NOT cross-compiling, and a configure test has determined that a certain
system function is buggy or missing, what would be the point of disabling
the workaround? Even for your situation as an OS developer, Gnulib doesn't
hide the issues: It mentions the test results in the configure output,
and you even a sample program to reproduce each problem (embedded in the
config.log).
Regarding 1): This categorization exists in the documentation [1][2].
Should we go as far as splitting gnulib into 3 git repositories? I think
it would complicate things too much, because
- most packages borrow modules from all three kinds,
- there are dependencies not only from the utility modules to the
POSIX emulation modules, but also the other way around (e.g. to
the modules assure, c-ctype, filenamecat, flexmember, gettext-h,
integer-length, localcharset, localename, minmax, scratch-buffer,
verify).
Bruno
[1] https://www.gnu.org/software/gnulib/manual/html_node/index.html
[2] https://www.gnu.org/software/gnulib/MODULES.html
