bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: The non-recursive-gnulib-prefix-hack module
Date: Sun, 27 Nov 2016 23:02:20 +0100
User-agent: KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; )

Hi John,

> I also started working on a change to replace the 
> non-recursive-gnulib-prefix-hack module with a --non-recursive-makefile 
> option for gnulib-tool.  My initial attempt is attached.

Great!

A couple of small remarks:

* 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
      echo "MOSTLYCLEANFILES $assign core *.stackdump"
    else
      echo "MOSTLYCLEANFILES $assign ${sourcebase}core ${sourcebase}*.stackdump"
    fi
  [btw. I think the then / else branches ought to be swapped]
  contains some code duplication. To avoid it, I would define a shell variable
  relsourcebase = (${sourcebase} if $non_recursive, "" otherwise).
  This will avoid code duplication.

* lt_prefix="${libname}_${libext}_"
  The prefix 'lt_' makes it sound as if it's something tied to libtool. Which
  is not the case here: this variable is useful also when building a static
  library (Automake doesn't even reference libtool in this case). I would rename
  it to libamprefix or automake_variables_prefix or something like that.

> I am stuck trying to figure out what to do about 
> the Makefile.am snippets that appear in module files.  I'm not sure 
> exactly where the file names in lines like
> 
>    lib_SOURCES += xsize.c xsize.h
> 
> should be prefixed with the $sourcebase directory name or exactly how to 
> handle the rules that might be included there.

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.

> For example, I think things like
> 
>    # 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
>    errno.h: errno.in.h $(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)/errno.in.h; \
>            } > address@hidden && \
>            mv address@hidden $@
>    else
>    errno.h: $(top_builddir)/config.status
>            rm -f $@
>    endif
> 
> from modules/errno will need to have $(sourcebase) included in a few key 
> spots:
> 
>    # 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
>    SOURCEBASE/errno.h: SOURCEBASE/errno.in.h $(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)/SOURCEBASE/errno.in.h; \
>            } > address@hidden && \
>            mv address@hidden $@
>    else
>    SOURCEBASE/errno.h: $(top_builddir)/config.status
>            rm -f $@
>    endif

Here the goal is to continue to keep the code in the module descriptions
as simple and straightforward as possible. 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
?

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

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]