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 @LIMITS_H@.
> 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
