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

[John W. Eaton]

On 11/27/2016 05:02 PM, Bruno Haible wrote:

> * I would add a check to make sure that --non-recursive-makefile is
>   only used together with the --makefile-name option. I cannot see how/why
>   someone would use --non-recursive-makefile without --makefile-name.
>   This simplies some of the logic (e.g. the AUTOMAKE_OPTIONS handling).

> * Code like this
>     if $non_recursive; then

> * lt_prefix="${libname}_${libext}_"

OK, I can make these changes.

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

> Here the goal is to continue to keep the code in the module descriptions
> as simple and straightforward as possible.

Yes, I agree.

> This means that it needs to
> be postprocessed. Such preprocessings already exist, e.g.
> sed_replace_include_guard_prefix and sed_replace_build_aux are such
> preprocessings, cf. function func_emit_autoconf_snippet.
> Try to make the postprocessing as robust as possible. For example, a
> substitution that replaces $(srcdir) by $(srcdir)/SOURCEBASE seems robust.
>
> 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. 
Here's what happens when I run make in a tree where nothing has changed 
in the sources:

  coredump:1358> make -j9
  make  all-am
  make[1]: Entering directory '/tmp/foo-build'

  Octave successfully built.  Now choose from the following:

     ./run-octave    - to run in place to test before installing
     make check      - to run the tests
     make install    - to install (PREFIX=/usr/local/octave/dev)

     HG ID for this build is "c88f88296789+"

  make[1]: Leaving directory '/tmp/foo-build'

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?

BTW, this is really awesome because now there is no recursive invocation 
of make to process anything, gnulib or otherwise, so it just finishes 
with the summary message and make finishes this job in about 9 seconds 
on my system instead of 18.

> However, a substitution that replaces errno.h by SOURCEBASE/errno.h is
> not robust. Probably we need some kind of annotation that can be
> recognized by the preprocessing, e.g. let the snippet in the module description
> read:
>
>     # We need the following in order to create <errno.h> when the system
>     # doesn't have one that is POSIX compliant.
>     if GL_GENERATE_ERRNO_H
>     @address@hidden: @address@hidden $(top_builddir)/config.status
>             $(AM_V_GEN)rm -f address@hidden $@ && \
>             { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
>               sed -e 's|@''GUARD_PREFIX''@|${gl_include_guard_prefix}|g' \
>                   [...] \
>                   < $(srcdir)/@address@hidden; \
>             } > address@hidden && \
>             mv address@hidden $@
>     else
>     @address@hidden: $(top_builddir)/config.status
>             rm -f $@
>     endif
>
> 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 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.

jwe