Re: The non-recursive-gnulib-prefix-hack module

[Bruno Haible]

Hi Mike,

> Hi, I had attempted to get non-recursive-gnulib-prefix-hack working with
> Octave (where the gnulib subdirectory is not named 'lib'). I sent a
> patch and a query for help to bug-gnulib last year and attracted no
> interest, I assume because there are very few users.
> 
> Original (work-in-progress) patch attached, and see
> http://lists.gnu.org/archive/html/bug-gnulib/2015-08/msg00000.html,
> still valid because Octave has still not managed to incorporate gnulib
> cleanly into its non-recursive build.

The change to m4/non-recursive-gnulib-prefix-hack.m4 is no longer needed after
the two patches that I've submitted these days.

The change to gnulib-tool is not something I like: Replacing fixed strings
by variable strings a posteriori is a technique that produces good results
quickly but becomes more and more fragile the more it grows.

The change to build-aux/prefix-gnulib-mk is IMO lacking a conversion:
non-alphanumeric characters in $dir should be replaced by underscores. For
example, if $lib_name = "gnulib-lib", you don't want to produce a Makefile.am
variable name 'gnulib-lib_libbison_a_SOURCES' but rather
'gnulib_lib_libbison_a_SOURCES'.

> I'd be grateful for any thoughts or help on making this module work more
> generically.

The idea would be to have gnulib-tool emit the correct code for the
{Bison,coreutils,Octave} case right away, triggered by some command line
option.

If you want to help us here, please use the *current* gnulib-tool to
generate Makefile.am files. Then hand-edit these Makefile.am files with
a minimum of changes, so that they work in a non-recursive build (possibly
based on what prefix-gnulib-mk would produce). Then send us these files
(both the original and the edited Makefile.am) files, so that we can see
how gnulib-tool should be modified.

Bruno