On 2024-10-12 06:29, Michael Pratt via Patches for Automake wrote:
> When gnulib-tool or a bootstrap script uses the option --local-dir,
> include the "modules" files in a release with DIST_COMMON. Otherwise,
> these source files are present in checkouts but not in distribution.
I agree that missing these files is a real problem. A source tarball
should include all the necessary source code.
Users should not be expected to track down random upstream development
repositories, which may not even be publically accessible and probably
contains source code for many different versions, just to find the
source code that corresponds to their version of a particular package.
> The resulting gnulib.mk from gnulib-tool has comments
> with the options used to generate it:
>
> # Generated by gnulib-tool.
> # Reproduce by:
> # gnulib-tool --import --local-dir=gl \
> # ...
Please note that --local-dir option to gnulib-tool can be specified more
than once to add multiple directories which are searched for files in
order. I don't think your regex will work properly in this case.
The local dirs are recorded in machine-readable form in gnulib-cache.m4,
this is where you should be looking for it, not parsing out comments.
> + if ($_ =~ /--local-dir=([^\\\s]*)/o)
> + {
> + push_dist_common ("\$\(top_srcdir\)/$1/modules")
> + if -d "$1/modules";
> + }
Files in a local directory will supersede almost any file from the
primary gnulib sources. It can contain much more than just a "modules"
directory, including per-file patches which are applied on top of what
gets copied in from gnulib. So I think this is not enough to ensure
all the sources are actually included.
For automatic distribution, this problem should probably be solved in
gnulib-tool, as only it knows which files from the local directories
were actually used. All it needs to do is all all these files to
EXTRA_DIST in the generated makefile snippet.
For my own packages, given that gnulib-tool does not do this today,
I solved this particular problem by:
(1) Each local module file includes m4 code to update a global m4_set,
listing all the source files it requires (including itself).
(2) At autoconf time, m4 reads the gl_LOCAL_DIR setting from
gnulib-cache.m4 (a colon-separated list of directories)
(3) At make time, a dist-hook takes this set of source files and list
of local directories to find and distribute the required files.
(4) At release time, checking that gnulib-tool --update works as
expected in an unpacked release tarball.
Obviously it would be easier if gnulib-tool did some of this for me
but the process seems quite acceptable overall.
Cheers,
Nick
