Re: Gnulib support

[Kevin Ryde]

address@hidden (Ludovic Courtès) writes:
>
> Please, do read the thread on `bug-gnulib'.

I did.

> Widespread libraries already fixed the problem,

No.

> the most straightforward solution being to
> use Libtool's `-export-symbols-regex' link option (which is a single
> line in `Makefile.am').

Alas doesn't help the static ".a".  You'll also notice in the libtool
manual the caution "no effect on some platforms".

> Did you actually hit a problem?

Neither you nor I will hit a problem.  The systems hurt are ones noone
here hardly ever has to use, which is why it's essential to be very
careful about supposed "help".

It's a great shame really the gnulib bits are being done as yet more
code plonked into every package, to be updated in every package for
every new non-standard system, etc.  The quantity of autoconf, automake,
libtool, gettext, etc already dedicated to egregiously non-free systems
is pretty sad.  If only someone would "bit the bullet" and make a gnulib
or gnuification scheme that brought all those systems (those anyone
cares enough about) up to a gnu level in one hit. :(

> And while we're at it, I suggest that we do "mv libguile/*.[ch] .".
> Subdirs like that are unnecessary, too.  :-)

Don't move stuff about for no reason.  I've asked you before please not
to do things like that just because you feel like it.  It's not year
zero, and there's not enough manpower for actual fixes let alone notice
unintendend consequences of supposed cosmetic changes.  Hiding the build
tools in a subdir is pointless, its only effect is to obscure the
machinery, invalidate a paragraph in the INSTALL file, and give a nice
chance of breaking bits in the tree that assume things are where they
always have been.

> Hmm, I did not move the licence in `NEWS', though I did remove a few
> lines from there [0].  Is this what you are referring to?

The "dist-hook" rule is the best place to make dist-time consistency
checks.  A grep there can do what "check-news" does, but without having
to mangle the file, and indeed with a tighter regexp pattern to suit the
actual format used.  Assuming this is something really wanted at all --
since it should be clear dist restrictions must be made sparingly or
they're just pains in the proverbial.

The sole dist check I've found any good has been looking for "fuzzy"s in
po files, since gettext frequently makes extremely poor guesses at new
message translations.  On the other hand an example of a check that's
too agressive for a dist restriction is demanding all files modified
this year should have this year in the copyright line.  Worth grepping
from time to time, but too easy to get a false miss.