Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Remember, please don't use upstream-provided bootstrap unless necessary (http://www.linux-archive.org/gentoo-development/100804-remember-please-dont-use-upstream-provided-bootstrap-unless-necessary.html)

06-04-2008 04:46 PM

Remember, please don't use upstream-provided bootstrap unless necessary
 
I stumbled across another ebuild today that used the upstream-provided
bootstrap script to rebuild autotools.

Please refrain from using those if you can.

Upstream doesn't always know better for our setup (it may try to second
guess our settings by looking for particular automake/autoconf
versions), it will show to the user information we don't care about,
almost all the bootstrap scripts I've seen don't even try to catch when
a step in the rebuild fails, they mask the need for autotools, and as
you don't inherit autotools eclass for running them, you usually forget
to add the autoconf/automake dependencies. And it makes very difficult
to track down which ebuilds do actually use autotools to track down if
there are changes to do.

Let's not even start to talk about bootstrap scritps that run
./configure by themselves, those are just plainly evil.

Please note that sometimes the bootstrap script is used to add extra m4
search directories and options like --foreign to automake. Well, here's
the deal:

- AT_M4DIR is the variable to use to pass extra m4 search directory to
aclocal, no need for the bootstrap script;
- eautomake takes care by itself to identify the cases where --foreign
is needed (this usually means when some of the standard documentation
files are missign);

beside, if upstream is providing a bootstrap script for just these two
reasons, then it's time they learn about ACLOCAL_AMFLAGS.

Also make sure that autotools gets not rebuilt through maintainer mode,
that will make the configure run twice, wasting users' time, and is
usually evil if you are using unpack to check for the generated
configure (yes it happened to me a couple of time).

THANKS!

--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

06-04-2008 05:22 PM

Remember, please don't use upstream-provided bootstrap unless necessary
 
flameeyes@gmail.com (Diego 'Flameeyes' Pettenò) writes:

> Please refrain from using those if you can.

As I was asked for an example see this commit I made today:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-backup/boxbackup/boxbackup-0.10.ebuild?r1=1.9&r2=1.10

the original ebuild used the bootstrap script (in src_compile by the
way, which is very bad for me), and depended on autoconf directly,
without forcing which version should have been used.

The new version instead uses autotools.eclass, calls eautoreconf, sets
its AT_M4DIR as the bootstrap script did (and again, ACLOCAL_AMFLAGS is
what upstream should have used).

This way warnings and errors from autotools won't be seen by the users,
but will be logged in case stuff fialed, and you don't have to rely on
the bootstrap script not making stupid stuff.

--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

Enrico Weigelt 06-09-2008 09:18 PM

Remember, please don't use upstream-provided bootstrap unless necessary
 
* Diego 'Flameeyes' Pettenò <flameeyes@gmail.com> schrieb:

Hi,

> Upstream doesn't always know better for our setup (it may try to second

there are also a lot of other things, upstream tends not to know ;-P

> guess our settings by looking for particular automake/autoconf
> versions), it will show to the user information we don't care about,

ah, don't forget those upstreams (eg. mozilla) who are too lazy for
fixing their stoneage'd configure.in's for a more recent autoconf
version, instead invest enormous amounts of time in writing whole
books about why they're unwilling to have a look at ready-to-run
and well tested patches.

> almost all the bootstrap scripts I've seen don't even try to catch when
> a step in the rebuild fails, they mask the need for autotools, and as
> you don't inherit autotools eclass for running them, you usually forget
> to add the autoconf/automake dependencies. And it makes very difficult
> to track down which ebuilds do actually use autotools to track down if
> there are changes to do.

hmm, isn't it obvious that these scripts are just for the (upstream)
devs themselves ?

they belong into my (manual ;-)) "veryclean" stage when starting to
work on some package, same as ./configure, aclocal.m4, etc, etc ;-P
(for a clean start, I normally wipe out *everything* that's autogenerated)

> Let's not even start to talk about bootstrap scritps that run
> ./configure by themselves, those are just plainly evil.

ACK. We should instead ask the upstream for cleaned-up releases ;-)

Actually, I wouldn't even take the shipped ./configure scripts -
I *always* run the whole autoreconf chain on a fresh tree.

> Please note that sometimes the bootstrap script is used to add extra m4
> search directories and options like --foreign to automake. Well, here's
> the deal:
>
> - AT_M4DIR is the variable to use to pass extra m4 search directory to
> aclocal, no need for the bootstrap script;
> - eautomake takes care by itself to identify the cases where --foreign
> is needed (this usually means when some of the standard documentation
> files are missign);

I prefer to fix these broken configure.in's ;-P

> Also make sure that autotools gets not rebuilt through maintainer mode,
> that will make the configure run twice, wasting users' time, and is
> usually evil if you are using unpack to check for the generated
> configure (yes it happened to me a couple of time).

That strange "maintainer mode" is one of the things on my "to-rip-off"
list, along with the rules for regenerating the configure script.
(which sometimes tends to loop forever) ;-o



cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list


All times are GMT. The time now is 02:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.