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

[Bruno Haible]

John,

> I added
> 
>    AC_CONFIG_LIBOBJ_DIR([libgnu])
> 
> to my configure.ac file.  Maybe gnulib-tool could do this automatically 
> if --non-recursive-makefile is specified?

gnulib-tool does not rely on AC_LIBOBJ and friends, because these autoconf
macros assume that there is only one lib/ dir, whereas it is possible to
have several gnulib-tool invocations in the scope of a single configure.ac
file. Instead, the gnulib-tool generated gl_INIT method provides its own
definition of AC_LIBOBJ for the scope of the modules and .m4 expansions
that it pulls in.

Therefore you should not need this
    AC_CONFIG_LIBOBJ_DIR([libgnu])
invocation.

> it demonstrates what changes need to be made.

This is very good to see.

One thing I don't like is to put directory names into the *.m4 files;
this is
  1. against the principle that *.m4 files should determine properties
     of the platform, whereas Makefile.am contains file names,
  2. a problem w.r.t. the requirement above to be able to use
     several gnulib-tool invocations.

So, instead of replacing
    LIMITS_H=limits.h
by
    LIMITS_H=libgnu/limits.h
I would prefer to replace
    AC_SUBST([LIMITS_H])
by
    gl_FILENAME_SUBST([LIMITS_H])

Here gl_FILENAME_SUBST is a (yet to be written) autoconf macro that takes
a variable as argument that contains a space-separated list of file names.
It prepends ${relsourcebase} to each of these file names. Then it uses
AC_SUBST to enable the substitution of @address@hidden

> It would also be great if there were some automake magic or if we 
> could fix gnulib-tool to do these things automatically, but I don't see 
> how at the moment.  I imagine that automatically modifying the contents 
> of things like EXTRA_DIST or BUILT_SOURCES might be possible, but I 
> don't see how to automatically adjust the hand-coded makefile snippets.

Right. When gnulib-tool generates only a part of Makefile.am, it must leave
some choices to the programmer. But we can print a message at the end of
the gnulib-tool run about what is recommended: the "Don't forget to"
section, around line 5750.

> > Yes, the lib_SOURCES augmentations (and likewise with EXTRA_DIST and 
> > probably
> > a few others as well) need to be edited, adding the value of 
> > ${relsourcebase}
> > in front of each file name.
> 
> I can look, but I'm not sure where to do that job.  If you can quickly 
> point to the spot where it needs to happen that will help, otherwise I 
> will do some searching.

Probably near func_get_automake_snippet.

> > Btw. does
> >        SOURCEBASE/errno.h: SOURCEBASE/errno.in.h
> > work at all? Or do you need to write
> >        SOURCEBASE/errno.h: $(srcdir)/SOURCEBASE/errno.in.h
> 
> I think it should using the VPATH rules and it does appear to work. 

Good. Fine.

> I assume if SOURCEBASE/errno.in.h was wrong, it would fail with some 
> message about not being able to find or make the prerequisite?

Yes.

> > This can safely be transformed through "s|@FILE@|SOURCEBASE|".
> 
> OK, I can try to make that change.  Are you thinking that this 
> transformation should be done by gnulib-tool, or using a configure 
> substitution?

It should be done by gnulib-tool:
  1. because it can already be done at this stage,
  2. so that different gnulib-tool invocations in the scope of a single
     configure file work.

> It seems like that would be easy enough just by arranging 
> to do something like
> 
>    gl_SOURCEBASE=$sourcebase
>    AC_SUBST(gl_SOURCEBASE)
> 
> in the configure script and then using this variable in the snippets 
> where you used @FILE@ above.

There is a variable gl_source_base in the configure script, set at the
beginning of gl_INIT. You can use it as a shell variable. But it is not
(and cannot be) AC_SUBSTable.

Bruno