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

[Bruno Haible]

Hi John,

> I did that for Octave and the resulting files are attached.

This is great!

> The gnulib-generated file is Makefile.am.  The edited file that I 
> included in Octave's main Makefile.am file is module.mk.
> ...
> Things like AUTOMAKE_OPTIONS need to be omitted.  We can assume that the 
> top-level Makefile.am file will define that.
> 
> Variables like SUBDIRS, noinst_HEADERS, etc. don't need to be 
> initialized.  The top-level Makefile.am file should do that and the 
> makefile fragment that gnulib-tool generates should just append to these 
> variables.

When you specify --makefile-name=module.mk, gnulib-tool knows that you
don't want a top-level Makefile.am and does not generate AUTOMAKE_OPTIONS
and generates augmentations (+=) of the other variables instead of assignments.

> Additionally, I had to edit the definitions of gl_LIBOBJS and 
> gl_LTLIBOBJS in the generated Makefile to add the source-base prefix (we 
> use "libgnu/" in Octave).
> 
> The libgnu_la_FOO variables need to be libgnu_libgnu_la_FOO instead 
> (again assuming source-base is "libgnu/").
> 
> libgnu_libgnu_la_CPPFLAGS needs to be set so that libgnu/ headers are 
> correctly found in the source and build trees.
> 
> Source and target file names need to be adjusted so that they are found 
> in the libgnu/ directory.
> 
> The generated makefile fragment contains some things like @address@hidden  I 
> didn't do anything with those, but something will probably need to 
> change so that they have the proper directory prefix added to the 
> substituted values.
> 
> Rules like the ones that generate alloca.h, dirent.h, etc., need to be 
> fixed to find the source files in $(srcdir)/libgnu/FOO.in.h instead of 
> just $(srcdir)/FOO.in.h.

Yes, these are the things that gnulib-tool should do differently, when
the option --non-recursive-makefile is given.

> There were some instances of using a file name like address@hidden  That 
> doesn't 
> work if $@ contains a directory component so I changed them to address@hidden 
> instead.

Yes, this is safe, even independently of the option --non-recursive-makefile.
(I had used t-$@ in order to avoid problems on file systems with limited
filename length, such as MINIX, FAT, or similar. But nowadays every file system
that people use for development has filename_max_length > 200.)

Bruno