Re: [fetchmail-devel] automake migration

[Matthias A. <ma...@dt...>]

Rob Funk <rf...@fu...> writes:

>> A bug the commit would also fix is the generation of text from HTML,
>> which can currently create empty files if lynx isn't installed.
>
> I was actually wondering about moving that generation out of the makefile 
> and into the makerelease script.  Not sure though.  That was mainly 
> prompted by the conversion of the man page to HTML, which requires some 
> infrastructure that we're not only not distributing, but isn't all that 
> common.  (Mainly the manServer.pl script I added to the dist-tools 
> directory.  Note that I don't intend for dist-tools to be included in the 
> release, and I hope to move a bunch of Eric's release scripts into there.) 
> I figured that if that conversion doesn't work with the distributed 
> tarball, it's worth thinking about the same situation with the rest of the 
> HTML generation.

I had to add this to get "make distcheck" working. In the long run, it
might be worthwhile converting the documentation to DocBook XML where
appropriate, I believe ESR's doclifter can help with that, which will
directly open PDF, man and HTML output formats.

>> Rob, does this get your OK?
>
> The general idea sounds good, especially the fact that you've tested on 
> multiple platforms.  The number of files touched is a bit scary, and I 
> have minor reservations about some fringes of the process, but I think we 
> can work those out later.

Most of the stuff is auto-generated and will be copied into the build
directory by autopoint, some will be copied by automake --add (this is
all automatic by running autoreconf -i)

> Unfortunately I'm going on an 8-day camping trip in a couple days and don't 
> have time to look closely at this before I go.  So I'll just suggest that 
> you go ahead and commit it, but try to commit in coherent chunks if 
> possible.

I fear the whole stuff is fairly atomic in the sense that I've only
tested with the full change set applied, not in separate. configure.in
and Makefile.am in particular track the po/ intl/... changes, and using
automake/aclocal only enables us to use the m4/ subdirectory which takes
the aclocal.m4 maintenance entirely off our shoulders.

> That is, see if you can separate the automake stuff, the HTML
> generation, and the gettext stuff.  I understand if that's not really 
> possible though.

automake and gettext is coupled, and HTML generation is a minor change,
effectively, the separate lines have been consolidated in a shell script.

> Meanwhile, be sure to test actually running the result.  (Argh, I still 
> have to figure out how to deal with the torturetest server list, with its 
> unpublishable passwords.)

Will do.

> It might be good to create a "bootstrap" script that removes that cache 
> directory and does the autoreconf.  And then change the makerelease script 
> to call that instead of "aclocal && autoconf".

I don't like custom bootstrap scripts much.
I have yet to see one that is better than "autoreconf" - and
autom4te.cache will only need to be removed after a system upgrade, but
not on a fresh checkout, so most people will get away without rm -rf.

>> A      dist-tools/Makefile.am
>
> I wouldn't think we'd need a makefile there.

For the time being we'll need one if you want "make distcheck" to work,
which I'd recommend as it greatly simplifies testing if the generated
tarball is self-contained. We can still remove the stuff later if we
have a good solution before the release.

>> D      intl/ChangeLog
>> D      intl/Makefile.in
>> D      intl/VERSION
>> D      intl/bindtextdom.c
> .... and so on
>
> Where's this intl functionality now?

autopoint will create the intl/ directory and populate it if you have
gettext 0.13.0 or newer installed - this is the "generated files"
category (copied files actually) - just try the tarball and you'll see.

No jinx here, good magic. :)

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95