Re: [bug-gnulib] autogenerate m4/Makefile.am - with gnulib-tool?

[James Youngman]

On Wed, Mar 23, 2005 at 09:08:00PM +0100, Oskar Liljeblad wrote:
> gnulib-tool --import doesn't generate a Makefile.am file for the m4
> directory. Is there any reason for this? I can imagine some
> difficulties when the m4 directory is used for non-gnulib m4 files
> as well, though.

I agree that automatically generating those files could be helpful.
This doesn't happen at the moment, so I generate these automatically
in a separate script.

It's done like this (the code is an extract from the findutils code,
see "import-gnulib.sh"):


if "$1"/gnulib-tool --import --dir=. --lib=libgnulib --source-base=gnulib/lib 
--m4-base=gnulib/m4  $modules
then
    : OK
else
    echo "gnulib-tool failed, exiting." >&2
    exit 1
fi

cat > gnulib/Makefile.am <<EOF
# Copyright (C) 2004 Free Software Foundation, Inc.
#
# This file is free software, distributed under the terms of the GNU
# General Public License.  As a special exception to the GNU General
# Public License, this file may be distributed as part of a program
# that contains a configuration script generated by Automake, under
# the same distribution terms as the rest of that program.
#
# This file was generated by $0 address@hidden
#
SUBDIRS = lib m4
EOF

(
cat <<EOF
# Copyright (C) 2004 Free Software Foundation, Inc.
#
# This file is free software, distributed under the terms of the GNU
# General Public License.  As a special exception to the GNU General
# Public License, this file may be distributed as part of a program
# that contains a configuration script generated by Automake, under
# the same distribution terms as the rest of that program.
#
# This file was generated by $0 address@hidden
#
EOF
printf "%s" "EXTRA_DIST = "
cd  ./gnulib/m4
ls *.m4 | sed -e 's/$/ \\/' | sed -e '$ s/\\$//'
echo 
) > gnulib/m4/Makefile.am



# We also need config.rpath, because configure calls it, but for 
# some reason, "autoreconf -i" doesn't fetch it.  
for f in config.rpath
do
  (set -x; cp "$1"/config/"$f" . )
done



> Also, it would be nice if gnulib-tool created symlinks to the source
> files by default instead of copying. 

No, I disagree.  With findutils, gnulib is imported into a "gnulib"
subdirectory, which contains nothing except the Makefile.am files
generated as above, plus whatever "gnulib-tool" puts there.  The
result is then tested with the (insufficiently complete) findutils
test suite and ten released.  The release process is just done with
"make dist" which makes a tar archive of the code.  If the gnulib code
was a load of symbolic links, only the links would be added to the tar
file.  I cannot pass the -h option to tar while doing "make dist"
because the "make dist" target is automatically generated.   

So, what I'm trying to say is that using symlinks would make life
noticably harder for me, at least where findutils is concerned.


(note to self - change 2004 to $(date +%Y) )

> An option -c/--copy would force the copy mode instead, just like
> with automake etc. Would a patch be accepted? Or maybe --symlink
> should be implemented instead?

For the moment, as long as symlinking isn't the default, I don't mind.
In the future if symlinking were to become the default but the
autogenerated "dist" rule did the right thing anyway, I also wouldn't
mind.

Regards,
James.