[gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary

[gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]


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/


[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

[gentoo-dev] Re: Remember, please don't use upstream-provided bootstrap unless necessary

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

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/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary

[Enrico Weigelt]

* 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