libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: release procedure


From: Ralf Wildenhues
Subject: Re: release procedure
Date: Mon, 16 Nov 2009 23:26:18 +0100
User-agent: Mutt/1.5.20 (2009-08-09)

Hi Peter,

* Peter O'Gorman wrote on Mon, Nov 16, 2009 at 05:16:15PM CET:
> For some reason our release procedure calls for running make
> distcheck 5 times. This is a tad onerous

Agreed.

> (one make distcheck takes almost an hour on my system).

Hmpf.  If you have a multi-way system, try e.g.
  TESTSUITEFLAGS=-j6

for a four-core one.  I have a couple of local patches to use
parallel-tests for the old Libtool testsuite, but that makes things
a bit awkward.  Still, I should probably clean them up and post them
for review.

> HACKING asks for:
> * Run `make distcheck'
>   and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'
>   and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--program-prefix=g'
>   and `make distcheck CC=g++'
> 
> then later:
> * Run `make -fMakefile.maint git-dist' (which also runs make distcheck).
> 
> Seriously, wtf?
> 
> I suggest that just the first two would be adequate.

Either that, or limit some of these tests so they are still effective
but less expensive.  Certainly having both the last implied distcheck
and the first one is overkill.  The CC=g++ can help to avoid some test
failures elsewhere though.

> We also fetch latest config* and some automake files from git/cvs.
> These files are all included in automake releases, what's wrong with
> just using the automake versions. Ralf releases automake fairly
> regularly ...

Well, esp. config.guess often is newer, and not having the latest of
that greatly bothers users porting stuff to new systems.  Of all things,
this is one issue that I'd really like us to keep, also as it avoids
the implied serialization between Automake and Libtool.

> If we must continue to fetch (I did not do so for todays release
> because when I tried I got test failures in make check/distcheck
> etc.), then we need to change the Makefile to use git for the config
> project.

Yes.

> Why on earth do we have a commit script that just provides an opaque
> interface to git?

FWIW, I never use it.  Gary?

> Let's just use gnuupload from gnulib to upload the tarballs.
> Maintaining our own system is silly.

Fine with me.

> I think that's about all, I will provide patches for HACKING and
> Makefile.maint later.

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]