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