[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#9845: [PATCH 1/3] maint: use gnulib's maint.mk and support scrip
From: |
Gary V. Vaughan |
Subject: |
Re: bug#9845: [PATCH 1/3] maint: use gnulib's maint.mk and support scripts release procedure. |
Date: |
Mon, 24 Oct 2011 09:12:08 +0700 |
Hi Peter,
On 24 Oct 2011, at 08:22, Peter O'Gorman wrote:
> On 10/23/2011 11:03 AM, Gary V. Vaughan wrote:
>> By the end of this series, making a release still involves an awful lot
>> of waiting, but after passing the bevy of make distcheck variations
>> mandated in the README-release, is now a simple matter of:
>>
>> 1. libltdl/config/do-release-commit-and-tag 2.4.4 stable
>> 3. make stable
>> 3. gnupload --to ftp.gnu.org:libtool libtool-2.4.4.tar.gz
>> libtool-2.4.4.tar.xz
>> 4. libltd/config/gnu-web-doc-update
>> 5. git push origin master tag v2.4.4
>>
>
> So the daily snapshot system now has autobuild installed for the user that
> makes the snapshot. Please remove this as a hard requirement for bootstrap,
> we have autobuild.m4 in libltdl/m4 so that people are not required to have
> autobuild installed to reautoconf libtool.
Done. Sorry I forgot about that - I wrote bootstrap over the course of a few
months, testing that it successfully replaced the ugly gnulib bootstrap script
in bison, coreutils, libtool, m4, tar and zile... but having everything
installed here, I forget that we didn't need an installed autobuild.
Maybe it would be a better general solution to fix bootstrap so that it doesn't
automatically add a requirement for autobuild when it finds autobuild.m4
preinstalled in $macro_dir. WDYT?
> Gnulib is now a submodule, just for a document, a license file and a makefile?
Much, much more than that, check the contents of $gnulib_modules in
bootstrap.conf:
* announce-gen
instead of a ton of boilerplate blurb in HACKING, this module generates the
release announcements for us
* do-release-commit-and-tag
instead of a few adhoc rules in the old Makefile.maint, this module
automates the pre-release commit and git tree tagging
* gendocs
* gnu-web-doc-update
instead of the fetch rule and other glue in the old Makefile.maint, these
modules build and upload the libtool web manual
* git-version-gen
instead of all the scripts and documentation we were maintaining to fake out
the build system that we are still using CVS, this module creates a unique git
sha1 suffixed version number for non-releases, and otherwise streamlines our
version numbering system
* gitlog-to-changelog
instead of trying to keep git logs a and ChangeLog entries in sync, or
writing scripts to do that for us (clcommit.m4sh), just autogenerate the
ChangeLog from 2011 git log messages at dist time
* gnupload
instead of manually gpg signing releases and upload directives and manually
ftping them to the right machines on every release, do it all automatically
* maintainer-makefile
no need for hokey 'make -f Makefile.maint blah' to do all of the above, we
now have GNUMakefile, maint.mk to handle all of this, and can customize it with
cfg.mk.
* readme-release
instead of trying to document our painstaking release process (which really
did take me at least a day to go through manually for all previous releases)
this is the gnulib document for the gnulib release process.
Also, instead of having to manually sync up a bunch of files from elsewhere on
the web at release time, or hoping the versions of some of them from the most
recent automake relaease are new enough, gnulib keeps the following up to date
for us automatically as well, check the contents of $gnulib_non_module_files in
bootstrap.conf, and bootstrap:
* COPYING
* INSTALL
* doc/fdl.texi
* doc/gendocs_template
* libltdl/COPYING.LIB
* libltdl/config/compile
* libltdl/config/config.guess
* libltdl/config/config.sub
* libltdl/config/depcomp
* libltdl/config/gendocs.sh
* libltdl/config/install.sh
* libltdl/config/mdate-sh
* libltdl/config/missing
* libltdl/config/texinfo.tex
* libltdl/config/gendocs.sh
* libltdl/config/compile
Aside from all of this being much more streamlined and easier to use, it means
we're leveraging all the work and bugfixing provided by the gnulib maintainers
and the maintainers of other key GNU packages that use this stuff (coreutils,
tar, bison, gnutls and many more) so that we don't have to maintain our own
adhoc processes and scripts.
> What's with the top level gl/ dir?
This is the gnulib local overrides dir. From bootstrap.conf:
# Non-default gnulib directory options.
local_gl_dir=gl
Which is passed to the gnulib-tool invocation to apply any libtool tweaks to
the raw gnulib modules on checkout:
$ grep local_gl_dir bootstrap
local_gl_dir=
test -n "$local_gl_dir" \
&& func_append_u gnulib_tool_options " --local-dir=$local_gl_dir"
# any patches or replacements in $local_gl_dir are applied.
In due course, we can also offload maintenance of our argz code to gnulib, and
consider using one of the gnulib list management modules instead of our custom
slist code.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)