[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 22:29:10 +0100 |
User-agent: |
KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; ) |
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
Re: The non-recursive-gnulib-prefix-hack module,
Bruno Haible <=