[gentoo-dev] elibtoolize and when to drop it from an ebuild

[gentoo-dev] elibtoolize and when to drop it from an ebuild

[Roy Marples]

Hello List

The BSD team is starting to get a touch irritated by the constant
dropping of elibtoolize from ebuilds. We need this so that we get
nice .so version numbers as well as to fix a few libtool issues on the
BSD platforms.

Just because it's there doesn't mean it's safe to remove as it changes
nothing on your Linux box. But that's OK as I've been adding them back
when I find it dropped with a nice comment about the issue.

I do however take objection when the command AND the comment is removed.
Please stop this as you piss off our users who have to revdep-rebuild
needlessly.

Basically, if it has a fbsd keyword don't drop elibtoolize without
querying us first.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Duncan]

Roy Marples <uberlord@gentoo.org> posted
1192632876.2388.18.camel@uberlaptop.development.ltl, excerpted below, on 
Wed, 17 Oct 2007 15:54:36 +0100:

> Basically, if it has a fbsd keyword don't drop elibtoolize without
> querying us first.

What about putting it in an fbsd conditional?  That way Linux users don't 
have to deal with the step if it's unnecessary for them, while the fbsd 
users still get it when they need it.  Seems to me this should be a 
workable compromise, where people might otherwise be inclined to remove 
it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Donnie Berkholz]

On 19:51 Wed 17 Oct     , Duncan wrote:
> What about putting it in an fbsd conditional?  That way Linux users don't 
> have to deal with the step if it's unnecessary for them, while the fbsd 
> users still get it when they need it.  Seems to me this should be a 
> workable compromise, where people might otherwise be inclined to remove 
> it.

I prefer to avoid conditionals wherever reasonable, because then you 
just have more code paths to test.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Roy Marples]

On Wed, 2007-10-17 at 15:25 -0700, Donnie Berkholz wrote:
> On 19:51 Wed 17 Oct     , Duncan wrote:
> > What about putting it in an fbsd conditional?  That way Linux users don't 
> > have to deal with the step if it's unnecessary for them, while the fbsd 
> > users still get it when they need it.  Seems to me this should be a 
> > workable compromise, where people might otherwise be inclined to remove 
> > it.
> 
> I prefer to avoid conditionals wherever reasonable, because then you 
> just have more code paths to test.

What's more, elibtoolize does more than just fix any FreeBSD issues as
it fixes stuff for uclibc and darwin based platforms. It also fixes some
old crusty libtools in packages that affect Linux/glibc installs too.

So just because you don't need it, doesn't mean that someone else
doesn't either.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Petteri Räty]

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

Roy Marples kirjoitti:
> On Wed, 2007-10-17 at 15:25 -0700, Donnie Berkholz wrote:
>> On 19:51 Wed 17 Oct     , Duncan wrote:
>>> What about putting it in an fbsd conditional?  That way Linux users don't 
>>> have to deal with the step if it's unnecessary for them, while the fbsd 
>>> users still get it when they need it.  Seems to me this should be a 
>>> workable compromise, where people might otherwise be inclined to remove 
>>> it.
>> I prefer to avoid conditionals wherever reasonable, because then you 
>> just have more code paths to test.
> 
> What's more, elibtoolize does more than just fix any FreeBSD issues as
> it fixes stuff for uclibc and darwin based platforms. It also fixes some
> old crusty libtools in packages that affect Linux/glibc installs too.
> 
> So just because you don't need it, doesn't mean that someone else
> doesn't either.
> 
> Thanks
> 
> Roy
> 

I don't pretend to know much about elibtoolize but if it's so useful why
 it's not needed to always run it?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Roy Marples]

On Thu, 2007-10-18 at 02:08 +0300, Petteri Räty wrote:
> I don't pretend to know much about elibtoolize but if it's so useful why
>  it's not needed to always run it?

Not every package uses libtool, or other GNU autotools.
Sometimes it has to be run in specific directories instead of just the
toplevel one.

But also, consider this - if an ebuild supplies src_unpack and
src_compile how is it supposed to get called?

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Mike Frysinger]

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

On Wednesday 17 October 2007, Roy Marples wrote:
> What's more, elibtoolize does more than just fix any FreeBSD issues as
> it fixes stuff for uclibc and darwin based platforms. It also fixes some
> old crusty libtools in packages that affect Linux/glibc installs too.

you could consider these the same thing.  at least for uclibc, all fixes are 
in the latest versions of libtool, so elibtoolize isnt needed when the 
bundled build files are up-to-date.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Re: elibtoolize and when to drop it from an ebuild

[Mike Frysinger]

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

On Wednesday 17 October 2007, Roy Marples wrote:
> On Thu, 2007-10-18 at 02:08 +0300, Petteri Räty wrote:
> > I don't pretend to know much about elibtoolize but if it's so useful why
> >  it's not needed to always run it?
>
> Not every package uses libtool, or other GNU autotools.
> Sometimes it has to be run in specific directories instead of just the
> toplevel one.

irrelevant.  automatic patching/updating of build files should be integrated 
into src_unpack() just like gnuconfig_update was.  ive pawned this off onto 
Diego, but i dont know how far he got.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]