[RFC] a script to update our gnulib import...

[RFC] a script to update our gnulib import...

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

Hello,

My ultimate goal is to import gnulib's update-copyright to the list
of gnulib modules we import in the GDB sources. This is in preparation
for the 2012 Start of Year procedure which is going to come soon...
I thought I'd do it in two steps:

  1. Refresh our gnulib import to the latest sources;
  2. Add/import update-copyright.

This way, I know that the patch for the step 1 is a pure refresh.
And that the patch for step 2 is a pure import of a new module.

But the thing is, the import procedure is not completely obvious
to me. I eventually managed to make it work (meaning it built on
x86_64-linux) but I'm not sure I didn't break something on another
more exotic platform. Also, it's not clear to me which modules we
have imported so far.

This is why I thought the whole process should be somewhat done
by a script which anyone can run to do an update, or to add a new
module.  Attached is a first attempt at the script.

gdb/ChangeLog:

        * update-gnulib.sh: New script.

Still to be done/discussed:

 (a) Is the list of modules complete? I listed the three that I could
     figure out.  I deleted the whole gnulib/ subdirectory and
     recreated it using the script and GDB seems to build. Nothing
     seems to be deleted except some files in gnulib/extra
     (arg-nonnull.h, c++defs.h, warn-on-use.h). Are we using those?

 (b) Is the update procedure to regenerate configure, Makefiles et al
     complete? Right now, after the gnulib-tool is called, we do
     the following:

        aclocal -Ignulib/m4 &&
        autoconf &&
        automake

     Do we need to call autoheader, aclocal without argument, etc?

Thoughts?

Thanks,
-- 
Joel

PS: The suggestion to use gnulib's update-copyright was made because
    it handles more files than our emacs-based copyright.sh script
    does.  And it will hopefully be much faster as well.

[-- Attachment #2: update-gnulib.sh --]
[-- Type: application/x-sh, Size: 3153 bytes --]

Re: [RFC] a script to update our gnulib import...

[Alfred M. Szmidt]

   gdb/ChangeLog:

	   * update-gnulib.sh: New script.

Doesn't this do almost exactly what gnulib/build-aux/bootstrap does?
Wouldn't it be better to use that?

Re: [RFC] a script to update our gnulib import...

[Pedro Alves]

On Monday 12 December 2011 00:14:26, Joel Brobecker wrote:

> Still to be done/discussed:
> 
>  (a) Is the list of modules complete? I listed the three that I could
>      figure out

The last import is recorded at the top of gnulib/Makefile.am:

# Generated by gnulib-tool.
# Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=gnulib --m4-base=gnulib/m4 --doc-base=doc --tests-base=tests --aux-dir=gnulib/extra --no-libtool --macro-prefix=gl --no-vc-files memmem

memmem pulls in other modules we rely on as dependency, like e.g., stdint.
It'd be better to list them explicitly.  "memmem stdint wchar" does sounds
right.  The dependencies in current git may have changed since the last
import, so just pulling memmem today may not bring in all we currently have.

-- 
Pedro Alves

Re: [RFC] a script to update our gnulib import...

[Joel Brobecker]

Hi Pedro,

> The last import is recorded at the top of gnulib/Makefile.am:
> 
> # Generated by gnulib-tool.
> # Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=gnulib --m4-base=gnulib/m4 --doc-base=doc --tests-base=tests --aux-dir=gnulib/extra --no-libtool --macro-prefix=gl --no-vc-files memmem

Yeah, I had noticed that, which is where I started from...

> memmem pulls in other modules we rely on as dependency, like e.g., stdint.
> It'd be better to list them explicitly.  "memmem stdint wchar" does sounds
> right.  The dependencies in current git may have changed since the last
> import, so just pulling memmem today may not bring in all we currently have.

OK. I will also look at Alfred's suggestion (Alfred: to answer your
question, I just don't know enough about gnulib, and the documentation
still still quite sketchy - plus, we don't use automake in GDB, so
that adds an extra layer of interpretation).

-- 
Joel

Re: [RFC] a script to update our gnulib import...

[Alfred M. Szmidt]

   > memmem pulls in other modules we rely on as dependency, like
   > e.g., stdint.  It'd be better to list them explicitly.  "memmem
   > stdint wchar" does sounds right.  The dependencies in current git
   > may have changed since the last import, so just pulling memmem
   > today may not bring in all we currently have.

   OK. I will also look at Alfred's suggestion (Alfred: to answer your
   question, I just don't know enough about gnulib, and the
   documentation still still quite sketchy - plus, we don't use
   automake in GDB, so that adds an extra layer of interpretation).

If you'd like I can help you, the bootstrap script in gnulib doesn't
depend on automake I think.

Re: [RFC] a script to update our gnulib import...

[Joel Brobecker]

>    OK. I will also look at Alfred's suggestion (Alfred: to answer your
>    question, I just don't know enough about gnulib, and the
>    documentation still still quite sketchy - plus, we don't use
>    automake in GDB, so that adds an extra layer of interpretation).
> 
> If you'd like I can help you, the bootstrap script in gnulib doesn't
> depend on automake I think.

Thanks! What I am looking for, really, is have a module import list
somewhere, and a procedure that anyone can use to refresh our import.
It sounds from what you are saying like the bootstrap script could
help. From the little I've read in the gnulib doc, there might be
other ways as well, but one thing I'd like, is for us to maintain
explicitly the list of modules we directly import (that way, we can
always recreate the gdb/gnulib/ subdir, even after a wipe - the wipe
could be used to recreate from scratch for instance).

That's very kind of you. If you don't have time, don't sweat it.
But with our no-automake setup, it's hard sometimes to follow
the gnulib documentation. I usually end up figuring things out
through a combination of documentation and experimentation...

-- 
Joel

Re: [RFC] a script to update our gnulib import...

[Alfred M. Szmidt]

   Thanks! What I am looking for, really, is have a module import list
   somewhere, and a procedure that anyone can use to refresh our import.

That is exactly what ./bootstrap provides, you list the modules you
need in bootstrap.conf (the variable gnulib_modules), and bootstrap
takes care of the rest.

   That's very kind of you. If you don't have time, don't sweat it.
   But with our no-automake setup, it's hard sometimes to follow the
   gnulib documentation. I usually end up figuring things out through
   a combination of documentation and experimentation...

I'll look at it this week, and see that for example the gdb/gnulib/
directory doesn't have to be checked in.

Re: [RFC] a script to update our gnulib import...

[Tom Tromey]

>>>>> "Alfred" == Alfred M Szmidt <ams@gnu.org> writes:

Alfred> I'll look at it this week, and see that for example the gdb/gnulib/
Alfred> directory doesn't have to be checked in.

Yeah, it does.

GDB -- and more generally, the gcc and src trees -- have long had the
rule that most generated files, especially those required for
configury -- are checked in, and AM_MAINTAINER_MODE is used in
configure.

Tom

Re: [RFC] a script to update our gnulib import...

[Alfred M. Szmidt]

   Alfred> I'll look at it this week, and see that for example the gdb/gnulib/
   Alfred> directory doesn't have to be checked in.

   Yeah, it does.

   GDB -- and more generally, the gcc and src trees -- have long had the
   rule that most generated files, especially those required for
   configury -- are checked in, and AM_MAINTAINER_MODE is used in
   configure.

I was a bit unclear, I didn't mean that it shouldn't be checked in as
per what GDB does.  But that it doesn't `have' to be, i.e. that wiping
all generated files and doing ./bootstrap should restore it to working
order.