[Quilt-dev] auto~conf/make

[James Rowe]

Hey

  I wonder whether this mail could've been better written as a reply to
something else, but to be honest I think it will be served better
as new thread as it should be addressing points from all over the place
and contains some new material.

  So let me get somethings out of the way with first:

        1. If you don't like long mails kill this one now ;)  This has to be a
better approach then a different mail for each inter-dependant
query/answer though.

        2.

On Sat, 1 Feb 2003 13:01:31 +0100
Martin Quinson <address@hidden> wrote:

> Do you mean that sending tons of patches (and diff between patches
> versions) to the mailling list instead of commiting stuff to a tagged
> CVS is supposed to be easier for us? ;)
> 
> Or do you mean that all the patches do you send are only proof of
> concept, and that you need more time to finalize them? Looks good to
> me.

  Firstly, I wasn't entirely expecting it to work anywhere I hadn't
tested it as I knew it had severe problems(that at the time were
unfortunately second on the list after getting a working version in to
circulation here).

  Secondly, I had a strong feeling it(the direction) wouldn't be
accepted by the [granted small] masses anyway, and Andreas was right it
was a buggy mess.

  This version is not a proof of concept or awaiting finalisation as far
as I am concerned it works and well... however, I am not saying it is
bug free(but how bug ridden remains to be seen).

        3.

On Sat, 1 Feb 2003 19:47:32 +0100
Andreas Gruenbacher <address@hidden> wrote:

> backup-files is still lacking tests for the results of autoconf. Also 
> there should probably be a config.h[.in]. That's probably not a 
> priority right now, though. Support for copying files when hard links 
> don't work would be more important.

  Well, this version isn't going to solve that either.  I decided maybe
wrongly, that another way around it was just to let automake do the
business with the preprocessor.  Anyway, that is something
that needs to be discussed.  But my reasoning was there is only one file
that is going to use the config.h anyway, so I deemed it a little
pointless.

  Backup-files is still not going to react based on the results of
configure right now, but it would be pointless to start on that
now(at least until the model is chosen and in place).

>>   You may also notice that a new target dist-snapshot has been added,
>> so that stack of tarballs from dev versions should be a little easier
>> to manage(atleast for me).

>I don't know what it's really worth, but I've merged it in. I have
>moved
>ISODATE from configure.in to the makefile, though: You really want a 
>snapshot of the day you run `make snapshot', not of the day you ran 
>configure...

  In that case I haven't included it in this version, I can create it
with now `gen-snapshot' anyway.  And this way I don't need to make the
larger edits for reassigning the version numbers.

  I will explain why it was there though, when I get mail that says
'version 0.21 has a problem with x, y and z' it isn't even remotely
helpful. The intrusive edits that hadn't been added then were so when
people use quilt(mainly at work this way) they can tell me their version
simply.  We only do source installs at work, so a version called 0.21
that was built from quilt-head when they did a pkg-update is zero help.

[ To clarify that paragraph, we use a Gentoo style ebuild system at
work for almost all software.   People can pkg-update(er like 'apt-get
dist-update' if that is even the right command I've not used Debian
for over a year) whenever they feel like(well aslong as they own the
machine, which would need another mail just to explain how that
system works).]

  As for position of the ISODATE declare our different work practises
mean that could never cause a problem here.  But I guess Andreas is
right, if you do build a tarball from an old Makefile you would expect
the date to be today's.

        4. If you really wish to understand the lndir concern then I will write
another mail.  But to sum it up... until quilt is in a position that I
can just generate a single tarball that will work everywhere I need a
way to keep arch specific changes out of the main tree to save me time. 
There is *no* better way to do this then shadowing the work tree, and
implementing only the changes that are needed.  This way there is
pretty much no user intervention required.

  Although it would be nice to run with two build systems, it is not
something I have either the time or the inclination to do.

  So, if this gets rejected I will move back to the lndir situation...
and if not I will work from this.

        5.  The backup-files rename comments from Andreas

  This version also renames backup-files(.c) to backupfiles(.c) because
of automake.

[end of rambings]

  So then onto the real purpose...

  I need my best Tony Montana voice for this... "So you wanna see bugs? 
say 'ello to ma little friend"

  Changes:

        Automake
        guidiff is gone, Andreas' --diff option to `quilt diff' fills the
purpose without the need for another command.
        guards has had the internal pod docs removed, in favour of adding them
to the doc/quilt.xml file
        There is the start of a README, and some doc/ files.  I chose
docbook-xml today, as I had the stylesheets available.  Easy change
though, should someone raise concerns.  Right now the quilt.1 and
guards.1 are included in a dist-tar, along with the .xml.  The only time
you need xsltproc is if you remove quilt.1 or guards.1, and that is also
the only time you need to supply the path to the stylesheets at
configure time.
        All the .cvsignore files have been updated to reflect the changes,
although the debian one _really_ needs checking.
        There is a autogen in config/, which currently appears to be running an
extra command(autoconf --version) for no reason.  This is because I
haven't had time to track down the changes that had been causing
problems, made sense to spec it out now though.
        config/install-sh has been removed, and no other autoconf/automake
tools have been added.  I don't really feel they belong in CVS anyway.
        configure.ac has had the AC_REVISION removed, it is a little
unnecessary really if you have grabbed the CVS.  I don't know if anyone
else needed it anyway, but I don't anymore as I have access to other
ways to defer the package version now.
        A check for diffstat has been added in to configure.ac too, I think
really it should have been there already.
        The quilt.changes files has been moved to ChangeLog, if people would
rather have the old style then we could enforce automake's foreign mode
anyway.
        There have been some whitespace changes made in bin/, quilt/ and
scripts/ where it would appear some cut&paste happened with tabs
expanded to spaces.
        A couple of vim users at work have been moaning about broken syntax
highlighting as the result of some unquoted $#'s too, so they have been
changed.

  Working:

        Everything to the degree of testing it has had, except ...

  Possible issues:

        The debian stuff may or may not still work.  I only know one person who
uses debian and until he is back from Berege I can't ask for SSH access
so zero testing there
        The spec file is generated exactly the same way it was before, so the
RPM stuff may or may not work.  I have no interest in playing with RPM's
at all and no access to any machines with RPM installed(which I class
as a bonus).
        The docs are installed in /usr/share/doc/quilt, I am
curious however about the reason for /usr/share/doc/packages/quilt in
the original Makefile.in
        Right now it is installing all the docs and the wannabe docs, they are
a little more informative than nothing at the moment so why not?
        The reference target in docs/Makefile.am is ugly as hell
now, and very likely to cause future problems.  It almost causes
problems now(not for installs though), but that is down to the fact I
don't feel it has legs so didn't bother doing anything about it.  There
is a severe portability problem that has been introduced(by me
unfortunately), on systems who don't use GNU make as their make of
choice the reference target may fail completely(because of a quick
kludge to kill the 'make[*]: entering directory' rubbish which would
have ended up in doc/README otherwise.
        The spec and README files are build dependant, because they use
parse-patch and the generated scripts respectively.

  Not working:

        As far as I know, nothing.

  Once again the autogen.sh is in config/, and this time there /is/ a
full tarball available at
http://www.jnrowe.uklinux.net/quilt/quilt-0.22.tar.bz2 ;)

  You can also find a full CVS archive at
http://www.jnrowe.uklinux.net/quilt/quilt-0.22-cvs.tar.bz2 and, for as
little use as it probably is to you guys, a binary package at the same
place(the .tbz2).

  If these changes to move to automake are not accepted, then I will
repost the non-automake changes in patch format.

  A couple of files, documentation really, are in a seriously rough
state.  This is because I am heading off on a business trip for 4 days
tomorrow, and wanted to get the rest of this out of the way with first.

  The attached big ol' patch is against current CVS.

Jay

-- 

www.jnrowe.uklinux.net
GnuPG key fingerprint = 7721 D12B 822B 20FE FCE6  B2B7 7CDF C9DF D16A
87D7

quilt-cvs20030205-jr2.patch.bz2
Description: Binary data

pgpPvRgA5U5I9.pgp
Description: PGP signature