Re: [gentoo-dev] The future of elibtoolize

On Sun, Sep 25, 2016 at 5:05 AM, James Le Cuirot wrote: > Now I remember why I couldn't rely on bashrc for this. > elibtoolize comes from the libtool eclass and you can't inherit > additional eclasses from bashrc. This is what I'm dealing with all the time. It would be easier

Re: [gentoo-dev] The future of elibtoolize

On Tue, 27 Sep 2016 11:24:19 +0200 Alexis Ballier wrote: > > You said that flameeyes raised this about 10 years ago. It has > > indeed been 10 years! > > > > https://archives.gentoo.org/gentoo-dev/message/caa153de0d23dc264330f5e702f26e58 > > > > The solution he preferred

Re: [gentoo-dev] The future of elibtoolize

On Tue, 27 Sep 2016 22:52:08 +1300 Kent Fredric wrote: > On Tue, 27 Sep 2016 11:24:19 +0200 > Alexis Ballier wrote: > > > Also, keep in mind that with an external utility you have far less > > control on what is executed than with something in $PORTDIR:

Re: [gentoo-dev] The future of elibtoolize

On Tue, 27 Sep 2016 11:24:19 +0200 Alexis Ballier wrote: > Also, keep in mind that with an external utility you have far less > control on what is executed than with something in $PORTDIR: people may > use an older buggy version of the utility, while when shipping it in >

Re: [gentoo-dev] The future of elibtoolize

On Mon, 26 Sep 2016 21:35:29 +0100 James Le Cuirot wrote: [...] > > On the other hand, we could go the complete opposite direction of > > what has been done in the past years with PMS: provide a generic > > way to extend ebuild env from profiles, with the ability to > >

Re: [gentoo-dev] The future of elibtoolize

On Mon, 26 Sep 2016 17:53:43 +0200 Alexis Ballier wrote: > I doubt including elibtoolize in portage/econf/pms is a viable > solution: there is way too much code, N patches times M libtool > versions to handle, and in rare cases one needs to call elibtoolize > with some

Re: [gentoo-dev] The future of elibtoolize

On Sun, 25 Sep 2016 11:05:27 +0100 James Le Cuirot wrote: > I've just started cross-compiling again for the first time in about > two years. Now I remember why I couldn't rely on bashrc for this. > elibtoolize comes from the libtool eclass and you can't inherit > additional

Re: [gentoo-dev] The future of elibtoolize

> On Tue, 20 Sep 2016 15:32:05 > > Alexis Ballier wrote: > > > On Tue, 20 Sep 2016 16:21:36 +0100 > James Le Cuirot wrote: > > > On Tue, 20 Sep 2016 17:13:50 +0200 > > Alexis Ballier wrote: > > > > > On Tue, 20 Sep 2016 13:58:32 +0100 > > > James Le

Re: [gentoo-dev] The future of elibtoolize

On Tue, 20 Sep 2016 16:21:36 +0100 James Le Cuirot wrote: > On Tue, 20 Sep 2016 17:13:50 +0200 > Alexis Ballier wrote: > > > On Tue, 20 Sep 2016 13:58:32 +0100 > > James Le Cuirot wrote: > > > > > On Tue, 20 Sep 2016 09:15:50 +0200 >

Re: [gentoo-dev] The future of elibtoolize

On Tue, 20 Sep 2016 17:13:50 +0200 Alexis Ballier wrote: > On Tue, 20 Sep 2016 13:58:32 +0100 > James Le Cuirot wrote: > > > On Tue, 20 Sep 2016 09:15:50 +0200 > > Michał Górny wrote: > > > > > That said, I don't find the current

Re: [gentoo-dev] The future of elibtoolize

On Tue, 20 Sep 2016 13:58:32 +0100 James Le Cuirot wrote: > On Tue, 20 Sep 2016 09:15:50 +0200 > Michał Górny wrote: > > > That said, I don't find the current solution really optimal. A lot > > of ebuilds (mine, for example) are not using elibtoolize, and I

Re: [gentoo-dev] The future of elibtoolize

On Tue, 20 Sep 2016 09:15:50 +0200 Michał Górny wrote: > That said, I don't find the current solution really optimal. A lot of > ebuilds (mine, for example) are not using elibtoolize, and I expect > that they may randomly fail for some people in corner cases. But I > don't

[gentoo-dev] The future of elibtoolize

Hi, everyone. Quoting the top of libtool.eclass: # @DESCRIPTION: # This eclass patches ltmain.sh distributed with libtoolized packages with the # relink and portage patch among others # # Note, this eclass does not require libtool as it only applies patches to # generated libtool files. We do