Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

New eclass: autotools-multilib-minimal

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


hasufell at gentoo

Feb 23, 2013, 4:34 PM

Post #1 of 30 (1608 views)
Permalink
New eclass: autotools-multilib-minimal

Some people seem to feel uncomfortable with autotools-multilib, because
it depends on autotools-utils.

Instead of arguing whether it makes sense or not I'd propose a similar
autotools related eclass.

I also attach an example conversion of media-libs/libexif (the
maintainer wants to keep the changes minimal).
Effectively I am only (almost) changing the function names and not the
ebuild code.

Feel free to propose a different eclass name.
Attachments: autotools-multilib-minimal.eclass (2.94 KB)
  libexif-0.6.21.ebuild.diff (1.40 KB)


hasufell at gentoo

Feb 23, 2013, 8:22 PM

Post #2 of 30 (1575 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

Before people start asking I should explain why I started this:
https://bugs.gentoo.org/show_bug.cgi?id=458638

I think having such an eclass has several advantages over
autootools-multilib.eclass (which depends on autotools-utils.eclass) as
it is now:

a) Less eclass dependencies. One could argue: the more eclasses my
ebuild uses the more prone to error and exposed to changes it is.
b) easier conversion in some cases: often times a simple rename
src_compile -> multilib_src_compile will do
c) it allows more custom definition of phase functions
d) the previous point will also allow to convert go-mono.eclass packages
without introducing yet another eclass for that
e) autotools-utils.eclass does a bit more than just calling default
phase functions; the developer has little choice on this matter unless
he wants to rewrite his ebuild based on multilib-build.eclass which will
create a lot of code duplication in ebuilds, hence this proposition

I don't have a problem with the present eclasses, but I find this a
logical enhancement.


mgorny at gentoo

Feb 24, 2013, 2:06 AM

Post #3 of 30 (1565 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell <hasufell [at] gentoo> wrote:

> Before people start asking I should explain why I started this:
> https://bugs.gentoo.org/show_bug.cgi?id=458638
>
> I think having such an eclass has several advantages over
> autootools-multilib.eclass (which depends on autotools-utils.eclass) as
> it is now:
>
> a) Less eclass dependencies. One could argue: the more eclasses my
> ebuild uses the more prone to error and exposed to changes it is.
> b) easier conversion in some cases: often times a simple rename
> src_compile -> multilib_src_compile will do
> c) it allows more custom definition of phase functions
> d) the previous point will also allow to convert go-mono.eclass packages
> without introducing yet another eclass for that

Then don't put 'autotools' in the name.

> e) autotools-utils.eclass does a bit more than just calling default
> phase functions; the developer has little choice on this matter unless
> he wants to rewrite his ebuild based on multilib-build.eclass which will
> create a lot of code duplication in ebuilds, hence this proposition

Yes, everyone sees 'a bit more' but nobody so far was able to point
what it is exactly. Or people simply don't know what PMS does nowadays.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.94 KB)


flameeyes at flameeyes

Feb 24, 2013, 2:11 AM

Post #4 of 30 (1572 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On 24/02/2013 11:06, Michał Górny wrote:
> Then don't put 'autotools' in the name.

+1

> Yes, everyone sees 'a bit more' but nobody so far was able to point
> what it is exactly. Or people simply don't know what PMS does nowadays.

I've been trying to get myself to use autotools-utils more often lately,
especially since I think at this point, with multilib support easier to
wire in it than others, it would be the right way to proceed with (it's
going to be a ruddy mess with orthogonal ABIs such as Ruby's but I don't
want to go there right now).

The only thing that would upset me in all of this is something that is
unfortunately needed for multilib builds to not be completely idiotic,
and that is the out-of-source builds. I had to fix one package for that
already (lksctp-tools).

On the other hand I usually fixed that stuff anyway because I use
out-of-source builds when I'm developing them so...

Btw, I know I've been more than rough on Michał before, so I guess I'd
better say this out loud: I really like his roadmap toward multilib
support. Kudos!

--
Diego Elio Pettenò — Flameeyes
flameeyes [at] flameeyes — http://blog.flameeyes.eu/
Attachments: signature.asc (0.54 KB)


hasufell at gentoo

Feb 24, 2013, 6:17 AM

Post #5 of 30 (1566 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> On 24/02/2013 11:06, Michał Górny wrote:
>> Then don't put 'autotools' in the name.
>
> +1
>

That would be multilib-minimal.eclass then?

I find that name silly, but I don't have a better idea.


ABCD also suggested something else:
autotools-multilib.eclass -> autotools-utils-multilib.eclass
autotools-multilib-minimal.eclass -> autotools-multilib.eclass

that is more logical imo, but would maybe cause unnecessary hassle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKiEPAAoJEFpvPKfnPDWzF+UIAJ13DlLh6dIfY9zvbd9v3z48
7jiW9z/aeiEWYxy9KxM5zLRfosnNPGNbUiTjiozVq1gLFA4anJiEDO86iSaQIYJa
Uv5CoSNF7MZXFMEmNk0GoJqLQmzrhFyxYF27rqc+yt0B+unOcBlZ34DsUTJXTzQF
CxZY7QKiLonN35zPK72uJxaAW12i+/0YDlgU/Sji7cO57JXW23nA7Gue7pBY6ACm
rQi/aTzj2TEe+mWPoWFLgwPfk3EYeLPVev9ouVJMW6CHJRlf1gX6giVpMFnQQNfm
TgfCYvQaVYgh+oaKzmz5Kg9xu0NdhdA5GQI8SEcf658sNYXj3/dco0oVJIF3DgI=
=BHkt
-----END PGP SIGNATURE-----


pacho at gentoo

Feb 24, 2013, 6:33 AM

Post #6 of 30 (1561 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

El dom, 24-02-2013 a las 15:17 +0100, hasufell escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> > On 24/02/2013 11:06, Michał Górny wrote:
> >> Then don't put 'autotools' in the name.
> >
> > +1
> >
>
> That would be multilib-minimal.eclass then?
>
> I find that name silly, but I don't have a better idea.
>

Probably multilib-build-minimal.eclass :/
Attachments: signature.asc (0.19 KB)


mgorny at gentoo

Feb 24, 2013, 6:57 AM

Post #7 of 30 (1562 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell <hasufell [at] gentoo> wrote:

> Before people start asking I should explain why I started this:
> https://bugs.gentoo.org/show_bug.cgi?id=458638
>
> I think having such an eclass has several advantages over
> autootools-multilib.eclass (which depends on autotools-utils.eclass) as
> it is now:

You wanted the other points, so here you go.

> a) Less eclass dependencies. One could argue: the more eclasses my
> ebuild uses the more prone to error and exposed to changes it is.

That's as good as bundling libraries. Really.

> b) easier conversion in some cases: often times a simple rename
> src_compile -> multilib_src_compile will do

Easy != good. The eclass switch is a good point to fix bugs which
should have been fixed long ago. By making it unnecessary, you just
keep those bugs live and hidden.

> c) it allows more custom definition of phase functions

More custom than what?

> d) the previous point will also allow to convert go-mono.eclass packages
> without introducing yet another eclass for that

So you're introducing a hacky eclass just because you're too lazy to
convert go-mono packages properly and too impatient to let others do
the work properly for you?

> e) autotools-utils.eclass does a bit more than just calling default
> phase functions; the developer has little choice on this matter unless
> he wants to rewrite his ebuild based on multilib-build.eclass which will
> create a lot of code duplication in ebuilds, hence this proposition

And as I already told you, this argument just proves that you don't
know the eclass in question and just throwing random accusations.

> I don't have a problem with the present eclasses, but I find this a
> logical enhancement.

If that's logical, then please provide a graph showing where it
logically fits. Because so far, it's either hate-built redundant eclass
or quick draft eclass written for a single package.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.94 KB)


hasufell at gentoo

Feb 24, 2013, 7:12 AM

Post #8 of 30 (1581 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/24/2013 03:57 PM, Michał Górny wrote:
> On Sun, 24 Feb 2013 05:22:43 +0100 hasufell <hasufell [at] gentoo>
> wrote:
>
>> Before people start asking I should explain why I started this:
>> https://bugs.gentoo.org/show_bug.cgi?id=458638
>>
>> I think having such an eclass has several advantages over
>> autootools-multilib.eclass (which depends on
>> autotools-utils.eclass) as it is now:
>
> You wanted the other points, so here you go.
>
>> a) Less eclass dependencies. One could argue: the more eclasses
>> my ebuild uses the more prone to error and exposed to changes it
>> is.
>
> That's as good as bundling libraries. Really.

That analogy is flawed. It's about ebuild design and the fact that I
don't just convert my ebuild to _multilib_, but also to
_autotools-utils_, so I have to keep an eye on another provider.

>
>> b) easier conversion in some cases: often times a simple rename
>> src_compile -> multilib_src_compile will do
>
> Easy != good. The eclass switch is a good point to fix bugs which
> should have been fixed long ago. By making it unnecessary, you
> just keep those bugs live and hidden.
>
>> c) it allows more custom definition of phase functions
>
> More custom than what?

Than autotools-multilib.eclass.

>
>> d) the previous point will also allow to convert go-mono.eclass
>> packages without introducing yet another eclass for that
>
> So you're introducing a hacky eclass just because you're too lazy
> to convert go-mono packages properly and too impatient to let
> others do the work properly for you?

Please point out where the eclass is hacky. I haven't heard a
technical argument against it despite that you think
autotools-multilib.eclass is better.
That might be true, but then I don't understand why people refuse to
use it which is the only reason I am proposing this.

Also, I am not too lazy to convert go-mono packages. I have already
written the go-mono-multilib.eclass and it looks almost the same as
autotools-multilib-minimal.eclass, so I am wondering why I want
code-duplication in eclasses.

>
>> e) autotools-utils.eclass does a bit more than just calling
>> default phase functions; the developer has little choice on this
>> matter unless he wants to rewrite his ebuild based on
>> multilib-build.eclass which will create a lot of code duplication
>> in ebuilds, hence this proposition
>
> And as I already told you, this argument just proves that you
> don't know the eclass in question and just throwing random
> accusations.
>

No, I was just rephrasing other peoples concerns.

>> I don't have a problem with the present eclasses, but I find this
>> a logical enhancement.
>
> If that's logical, then please provide a graph showing where it
> logically fits. Because so far, it's either hate-built redundant
> eclass or quick draft eclass written for a single package.
>

I don't understand you.
It works on more than one package.


Anyway... as I said, I don't care how this problem is solved. I only
care about the availability of 32bit libs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKi3GAAoJEFpvPKfnPDWzkW4H/3uaQ++8Rky1GKi+Tvffz45i
x+yNpPtje/gWFKjXVeWxQZfNV/tLsq1TZM0ruzixB6lO1vFD6Ql+8ZiuTrHHRvuV
at3+iT2AycSTeNs0qRUHjICOn5V6fMNQyIxJsrFS+HNEEbYfE36+S91YvN9WwHr6
Q2PDBp+3jueJXNVeZh+zdSQL4eo2fEuJ39/pa42SPbeRGGm6aw1SnhD9RYBcRZuf
GyuTOk7R+vwp55i4d7xXyb8eEDVh7uSqikb7OniNA15a7wrmpSLsfwonhZS/a3Qq
R/pQDXGm+aDDk7ZwXGCWRvGd7ARLqED5A+5yKcfyQeZ99RP6KHW8+xEwkr8M54I=
=3uKD
-----END PGP SIGNATURE-----


pacho at gentoo

Feb 24, 2013, 7:12 AM

Post #9 of 30 (1561 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
[...]
> > d) the previous point will also allow to convert go-mono.eclass packages
> > without introducing yet another eclass for that
>
> So you're introducing a hacky eclass just because you're too lazy to
> convert go-mono packages properly and too impatient to let others do
> the work properly for you?

Would be nice to know what autotools-utils.eclass is doing differently
that is showing this problem with go-mono.eclass packages :/

Only one question, what is the reason for us having base.eclass and
autotools-utils.eclass? I still try to use plain ebuilds without
inheritting autotools-utils.eclass as I usually don't need it, probably
others do the same and refuse to have to inherit it only for multilib
support :/ How do you plan to solve this problem?

I would also like to hear why that people refuses to use
autotools-utils.eclass... because I don't have a strong opinion on this
topic
Attachments: signature.asc (0.19 KB)


mgorny at gentoo

Feb 24, 2013, 7:53 AM

Post #10 of 30 (1562 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 16:12:18 +0100
Pacho Ramos <pacho [at] gentoo> wrote:

> El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
> [...]
> > > d) the previous point will also allow to convert go-mono.eclass packages
> > > without introducing yet another eclass for that
> >
> > So you're introducing a hacky eclass just because you're too lazy to
> > convert go-mono packages properly and too impatient to let others do
> > the work properly for you?
>
> Would be nice to know what autotools-utils.eclass is doing differently
> that is showing this problem with go-mono.eclass packages :/

I already told that I'm going to look at this but I have too much work
to do right now so it's going to take a longer while.

> Only one question, what is the reason for us having base.eclass and
> autotools-utils.eclass?

I think that base.eclass is silently intended for removal at some point
in the future. While we're here, we should probably mark it deprecated.

autotools-utils does a bit more -- especially by using out-of-source
builds. The major reason to use autotools-utils so far was to support
those builds.

Believe me or not, the day I took over the maintenance of it I seen
the opportunity to use out-of-source builds for multilib. Today, both
python-r1 & multilib-build were specifically designed to allow using
out-of-source builds with minimal effort.

> I still try to use plain ebuilds without
> inheritting autotools-utils.eclass as I usually don't need it, probably
> others do the same and refuse to have to inherit it only for multilib
> support :/ How do you plan to solve this problem?

You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.

If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:

- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.

- patch applying and autoreconf in src_prepare() -- which are
completely optional, you are free to write your own src_prepare().
If you wanted to apply patches by hand, you'd need to write
src_prepare() anyway.

- adding libtool args for shared/static libs if IUSE=static-libs --
which I wanted to remove but people considered it useful.

> I would also like to hear why that people refuses to use
> autotools-utils.eclass... because I don't have a strong opinion on this
> topic

Well, the major argument was similar to yours -- why we should use
an eclass if default PMS functions work. But in the multilib case, they
do not work by design anymore.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.94 KB)


pacho at gentoo

Feb 24, 2013, 8:21 AM

Post #11 of 30 (1587 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

El dom, 24-02-2013 a las 16:53 +0100, Michał Górny escribió:
> On Sun, 24 Feb 2013 16:12:18 +0100
> Pacho Ramos <pacho [at] gentoo> wrote:
>
> > El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
> > [...]
> > > > d) the previous point will also allow to convert go-mono.eclass packages
> > > > without introducing yet another eclass for that
> > >
> > > So you're introducing a hacky eclass just because you're too lazy to
> > > convert go-mono packages properly and too impatient to let others do
> > > the work properly for you?
> >
> > Would be nice to know what autotools-utils.eclass is doing differently
> > that is showing this problem with go-mono.eclass packages :/
>
> I already told that I'm going to look at this but I have too much work
> to do right now so it's going to take a longer while.
>

In that case, sorry, I probably missed it for some reason :S

> > Only one question, what is the reason for us having base.eclass and
> > autotools-utils.eclass?
>
> I think that base.eclass is silently intended for removal at some point
> in the future. While we're here, we should probably mark it deprecated.
>

I agree, I though it was marked as deprecated time ago, but last time I
read it it appeared to be still "active"

[...]
> You generally have two options on doing multilib builds: either using
> out-of-source builds or in-source builds. If you decide on the latter,
> you unnecessarily waste users' time and disk space to create two more
> copies of sources. I don't think we should go this way.
>
> If you decide on out-of-source builds, you basically need proper
> src_{configure,compile,test,install} and that's what autotools-utils
> does. Plus:
>
> - prune_libtool_files in src_install() which most people want to do
> anyway, so that doesn't hurt -- and the pkg-config dep is going to
> be removed, by the patch I sent already.
>
> - patch applying and autoreconf in src_prepare() -- which are
> completely optional, you are free to write your own src_prepare().
> If you wanted to apply patches by hand, you'd need to write
> src_prepare() anyway.
>
> - adding libtool args for shared/static libs if IUSE=static-libs --
> which I wanted to remove but people considered it useful.
>
> > I would also like to hear why that people refuses to use
> > autotools-utils.eclass... because I don't have a strong opinion on this
> > topic
>
> Well, the major argument was similar to yours -- why we should use
> an eclass if default PMS functions work. But in the multilib case, they
> do not work by design anymore.
>

OK, thanks for the info
Attachments: signature.asc (0.19 KB)


aballier at gentoo

Feb 24, 2013, 8:22 AM

Post #12 of 30 (1566 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 01:34:47 +0100
hasufell <hasufell [at] gentoo> wrote:

> Some people seem to feel uncomfortable with autotools-multilib,
> because it depends on autotools-utils.

To be honest, I don't particularly like autotools-utils, I tend to
consider it a useless bloat. However, Michal's work on
autotools-multilib is IMHO the right thing to do: If you use the
autotools-utils syntax then it's trivial to support multilib without
useless duplication of code.
I still believe such an eclass as the one you propose is useful, except
it's not for autotools (at best temporary for broken autotools based
build systems): For example, I have no clue how to do multilib with
waf-based build systems without going the 'copy $S and run the usual
src_* phases in each directory for each ABI', which is what your eclass
is abstracting I think.

A.


aballier at gentoo

Feb 24, 2013, 8:28 AM

Post #13 of 30 (1556 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 16:53:02 +0100
Michał Górny <mgorny [at] gentoo> wrote:

> - prune_libtool_files in src_install() which most people want to do
> anyway, so that doesn't hurt -- and the pkg-config dep is going to
> be removed, by the patch I sent already.

A bit OT but that's one of the things I consider useless there, I
usually do 'find "${D}" -name '*.la' -delete' which is more than
enough in most cases, faster and avoids calling a 90+ lines function
which may break or add a pkg-config dep.


hasufell at gentoo

Feb 24, 2013, 8:42 AM

Post #14 of 30 (1566 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On 02/24/2013 05:22 PM, Alexis Ballier wrote:
> On Sun, 24 Feb 2013 01:34:47 +0100
> hasufell <hasufell [at] gentoo> wrote:
>
>> Some people seem to feel uncomfortable with autotools-multilib,
>> because it depends on autotools-utils.
>
> To be honest, I don't particularly like autotools-utils, I tend to
> consider it a useless bloat. However, Michal's work on
> autotools-multilib is IMHO the right thing to do: If you use the
> autotools-utils syntax then it's trivial to support multilib without
> useless duplication of code.
> I still believe such an eclass as the one you propose is useful, except
> it's not for autotools (at best temporary for broken autotools based
> build systems): For example, I have no clue how to do multilib with
> waf-based build systems without going the 'copy $S and run the usual
> src_* phases in each directory for each ABI', which is what your eclass
> is abstracting I think.
>
> A.
>

I have no idea if it makes sense for this package (since it also
installs binaries), but as an example I have converted dev-libs/serd.

And yes, a rename of the eclass would probably be appropriate.
Attachments: serd-0.18.2.ebuild.diff (0.99 KB)


ssuominen at gentoo

Feb 24, 2013, 8:58 AM

Post #15 of 30 (1563 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On 24/02/13 17:53, Michał Górny wrote:
>> I still try to use plain ebuilds without
>> inheritting autotools-utils.eclass as I usually don't need it, probably
>> others do the same and refuse to have to inherit it only for multilib
>> support :/ How do you plan to solve this problem?
>
> You generally have two options on doing multilib builds: either using
> out-of-source builds or in-source builds. If you decide on the latter,
> you unnecessarily waste users' time and disk space to create two more
> copies of sources. I don't think we should go this way.
>
> If you decide on out-of-source builds, you basically need proper
> src_{configure,compile,test,install} and that's what autotools-utils
> does. Plus:
>
> - patch applying and autoreconf in src_prepare() -- which are
> completely optional, you are free to write your own src_prepare().
> If you wanted to apply patches by hand, you'd need to write
> src_prepare() anyway.

It's that "Plus" part that is my problem with autotools-multilib.eclass
currently, it adds EXPORT_FUNCTIONS of src_prepare() from
autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
adds just another eclass/phase function to worry about for inherit order

>
> - prune_libtool_files in src_install() which most people want to do
> anyway, so that doesn't hurt -- and the pkg-config dep is going to
> be removed, by the patch I sent already.

but lacks a way to pass arguments to prune_libtool_files, like --all,
since prune_libtool_files isn't that smart it gets it right everytime
i propably prefer to stick to manually calling it with or without --all
and well, this is not related to the multilib conversion so it shouldn't
be executed anyway

> - adding libtool args for shared/static libs if IUSE=static-libs --
> which I wanted to remove but people considered it useful.

if it's not related to the multilib conversion, it shouldn't be executed...

>
>> I would also like to hear why that people refuses to use
>> autotools-utils.eclass... because I don't have a strong opinion on this
>> topic
>
> Well, the major argument was similar to yours -- why we should use
> an eclass if default PMS functions work. But in the multilib case, they
> do not work by design anymore.
>

src_prepare() seems to be adequate from PMS for the multilib conversion


abcd at gentoo

Feb 24, 2013, 10:05 AM

Post #16 of 30 (1557 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/24/2013 10:53 AM, Michał Górny wrote:
> I think that base.eclass is silently intended for removal at some
> point in the future. While we're here, we should probably mark it
> deprecated.
>

The problem with deprecating base.eclass and telling people to use
autotools-utils.eclass instead is that base.eclass also defines a
src_prepare that is used for eclasses that support *non*-autotools
build systems, such as cmake-utils.eclass. Requiring that support to
be copied around to each of the eclasses that currently inherits base
would allow the usual issues with copying code around.

- --
Jonathan Callen (abcd)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJRKlZ+AAoJELHSF2kinlg4L0UP/24ETiIoXIVS9it65p2s/YER
D/KCcgsbTMowWTrs488mQ8Vs/3T0Ij2sDuYRcOqqKEiDb6+aAeILhU3pDP9c8k7V
L8jV1RpF2nafO4dexXU9FBMd6KYvz3Vsf4JQfiHzybdBsVW9HE0vrU/lrST91tm8
irDxPfOWFMPGM3r8YD+AuQ6DlkgaMdnJnT+c9Bu5xtoGrjZ5inmSCeskQkX9zP54
wFFuwyg3+Db08r+qTHkUqnAPc1t3fSsz7X4tgQfX5btBjVgDKKYm2dsScjNmhvxg
4Wnv+A5R4QAcce3CWUOp/BXTAg6PuYBbGWZWm+5WzQstsZRRo+hiGh7buyIctdix
IRQaoNh7SRMiiV2STHJtjqz8+e28NsK16Na4PSbDM3GOYbiq+gb8dyDpvIQpzN6m
48G2dhETJpAvox6YnA6Ix9YDdoAl0Y25ynJSUajLbyQ9+rSiynIGnMT5UHFr9zaM
2zs9oXRaqO7Gj1A98nN0NwjC0U+sP7J2JidvcXbUO7YNx4exsgzUHdbrdG7gBpVd
iPHpECyrgh3uqIRS0j3bCR6WQAOBGb708hXrNj5a/ldGvYTYlLmt2Tbq+mJapZmp
uFLYrK1kwBmXj/3CSErO0Bg0lMspk8E0MnEljChdFPGYekkbPGhZKGp9EufczG+G
C5L3dv7V1Nv2AyyFiYB3
=cyEa
-----END PGP SIGNATURE-----


mgorny at gentoo

Feb 24, 2013, 10:18 AM

Post #17 of 30 (1561 views)
Permalink
Re: Re: New eclass: autotools-multilib-minimal [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 24 Feb 2013 13:05:51 -0500
Jonathan Callen <abcd [at] gentoo> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 02/24/2013 10:53 AM, Michał Górny wrote:
> > I think that base.eclass is silently intended for removal at some
> > point in the future. While we're here, we should probably mark it
> > deprecated.
> >
>
> The problem with deprecating base.eclass and telling people to use
> autotools-utils.eclass instead is that base.eclass also defines a
> src_prepare that is used for eclasses that support *non*-autotools
> build systems, such as cmake-utils.eclass. Requiring that support to
> be copied around to each of the eclasses that currently inherits base
> would allow the usual issues with copying code around.

If something inherits base.eclass, it should stop. autotools-utils used
to do that but I removed the inherit because of base_src_unpack() which
was exported for no reason and caused trouble with VCS eclasses.

- --
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRKlmBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC
QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKiF4P/1L6vB7oSI5xIq6mrE82h7iW
PNPWWRt+HBrLdK0u1uI/vuoGDs5/t02osGKNES0QVWRZz+70wRn8LBGoOp6A9Lz3
wEgguRDf6ppZc23Sr6uHXdr/mvAaTJezcJiME4eKoYXtda/eyZeiV22raZUktcGq
wRXQIzTDGwyYZcmq454J5DfU7ANlYU2uCTMGwWgq8l1ObP55tpJuirKu8mLx+lH2
TOVNnZmWJfqlcjd0updTQjpI8ijlc7Dn42c/kd0P1SpiP6mn7qEGfYy2lfLJWnWh
Z4LOnstwSlw1P6W09Htl8PHcLIGK1wA5ShvQVnfocnpuCpY8MXG+SrjYAA1RkWkZ
dzPNzo8VKqR8wrI/WIqkPmrfRRqsUgx07uGiGkn2L4gkZiiM3zUMTQvqHI2oGhGl
VE1xdG0Ca5O09U8FOdVJyUD8vO9xL7Ie5r8p35G6aRXrxEnQf8tYhCqbFyu/tq8V
f7L4QY6I+Jivk1XvpAq217tdRDykl6zl9D0LmFzQTtPXq/HAJDLkS+qZg7JpZ6bz
nsEv23jHPKeZ+WYOHvShFbgTUc1q+ky4F2qG7C4KrMJl7U6WRFqjCQdiDyfxLkNT
SiQ1fzZDBSFSZZvEbDUpqjz4Aj2R7x0DZ/lUPd52U7KCeK4KBQaOHXD0hsihvG3C
NJ3qcCqQWZYW9fR2wBP/
=huwA
-----END PGP SIGNATURE-----


aballier at gentoo

Feb 24, 2013, 10:46 AM

Post #18 of 30 (1545 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 17:42:26 +0100
hasufell <hasufell [at] gentoo> wrote:

[...]
> I have no idea if it makes sense for this package (since it also
> installs binaries), but as an example I have converted dev-libs/serd.

yes, that's the kind of usage of your eclass I was thinking about :)
(it might make sense to convert it but there is no need for it I know
about, there might arise some commercial binary-only package using it
some day)

> And yes, a rename of the eclass would probably be appropriate.

+1

Alexis.


mgorny at gentoo

Feb 24, 2013, 10:56 AM

Post #19 of 30 (1544 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Sun, 24 Feb 2013 18:58:08 +0200
Samuli Suominen <ssuominen [at] gentoo> wrote:

> On 24/02/13 17:53, Michał Górny wrote:
> >> I still try to use plain ebuilds without
> >> inheritting autotools-utils.eclass as I usually don't need it, probably
> >> others do the same and refuse to have to inherit it only for multilib
> >> support :/ How do you plan to solve this problem?
> >
> > You generally have two options on doing multilib builds: either using
> > out-of-source builds or in-source builds. If you decide on the latter,
> > you unnecessarily waste users' time and disk space to create two more
> > copies of sources. I don't think we should go this way.
> >
> > If you decide on out-of-source builds, you basically need proper
> > src_{configure,compile,test,install} and that's what autotools-utils
> > does. Plus:
> >
> > - patch applying and autoreconf in src_prepare() -- which are
> > completely optional, you are free to write your own src_prepare().
> > If you wanted to apply patches by hand, you'd need to write
> > src_prepare() anyway.
>
> It's that "Plus" part that is my problem with autotools-multilib.eclass
> currently, it adds EXPORT_FUNCTIONS of src_prepare() from
> autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
> adds just another eclass/phase function to worry about for inherit order

I understand your concern but I see no way around it. The alternative
solution exports src_prepare() as well to copy the sources -- so it's
even more to worry about than the no-op-by-default.

> > - prune_libtool_files in src_install() which most people want to do
> > anyway, so that doesn't hurt -- and the pkg-config dep is going to
> > be removed, by the patch I sent already.
>
> but lacks a way to pass arguments to prune_libtool_files, like --all,
> since prune_libtool_files isn't that smart it gets it right everytime
> i propably prefer to stick to manually calling it with or without --all
> and well, this is not related to the multilib conversion so it shouldn't
> be executed anyway

I can add the ability to pass arguments. So far, hasn't considered it
necessary since the single run doesn't really hurt anything noticeably.

> > - adding libtool args for shared/static libs if IUSE=static-libs --
> > which I wanted to remove but people considered it useful.
>
> if it's not related to the multilib conversion, it shouldn't be executed...

It's not about multilib conversion solely.

Multilib conversion requires out-of-source build support. Out-of-source
build support is established using autotools-utils. The logical
conversion order is to:

1) convert the ebuild to autotools-utils, make sure that out-of-source
builds work,

2) convert the ebuild to autotools-multilib.

Some of my conversions actually follow that split, providing two
patches instead of one.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.94 KB)


hasufell at gentoo

Feb 24, 2013, 11:40 AM

Post #20 of 30 (1544 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/24/2013 07:56 PM, Michał Górny wrote:
>> It's that "Plus" part that is my problem with
>> autotools-multilib.eclass currently, it adds EXPORT_FUNCTIONS of
>> src_prepare() from autotools-utils.eclass which is irrelevant to
>> the autotools-multilib.eclass adds just another eclass/phase
>> function to worry about for inherit order
>
> I understand your concern but I see no way around it. The
> alternative solution exports src_prepare() as well to copy the
> sources -- so it's even more to worry about than the
> no-op-by-default.

No, I don't export src_prepare. The developer has to call
"prepabisources" at the end of src_prepare himself, but only if he
wants to use IN_SOURCE_BUILD (this seems to be a requirement for
waf-utils ebuilds at first glance).

It's a bit similar to prepgamesdirs. I find it easier to require
calling it explicitly since src_prepare is often times a very custom
function.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKmyaAAoJEFpvPKfnPDWzQNsH/iMfm5+k2CuFwX1MEIf28DAp
4onvA2zEKCZCDMU4+eTLr3he04Qhy1NJb2WIqK4ZsRMHZvrtLoDR1PlLSgBN1Zs7
pYOTtOama9M6ha50jZmDptsG6GlZEWkuDvhYloHa1nKmCUaQdUJ6Cks53vkT1WmX
+Xaz/NJUCKARWj4yU6UzYxyh+kklLm/rSZPSDlpu329XD9aPUlRfH+QBQMY5S6gy
88VfbG0al+k0S7aB6Xj8gjCktj3ZLY0b4vMx6d0mrVw6sY1lJnz73Bd4NVCpW2QH
UlLDMthlVLOhRDIxaLcJcSOkEJ4/LDANSR45zQviurqUKjQy68Ve3DztlFaVEXo=
=lp6W
-----END PGP SIGNATURE-----


ssuominen at gentoo

Feb 24, 2013, 2:39 PM

Post #21 of 30 (1539 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On 24/02/13 02:34, hasufell wrote:
> Some people seem to feel uncomfortable with autotools-multilib, because
> it depends on autotools-utils.
>
> Instead of arguing whether it makes sense or not I'd propose a similar
> autotools related eclass.
>
> I also attach an example conversion of media-libs/libexif (the
> maintainer wants to keep the changes minimal).
> Effectively I am only (almost) changing the function names and not the
> ebuild code.

looks good, seems exactly what I wanted

> Feel free to propose a different eclass name.

whatever it will be, please make it shorter, like 'multiabi' maybe


ssuominen at gentoo

Feb 27, 2013, 5:01 AM

Post #22 of 30 (1533 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On 24/02/13 16:17, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
>> On 24/02/2013 11:06, Michał Górny wrote:
>>> Then don't put 'autotools' in the name.
>>
>> +1
>>
>
> That would be multilib-minimal.eclass then?

Sounds good to me.

> ABCD also suggested something else:
> autotools-multilib.eclass -> autotools-utils-multilib.eclass

This makes sense too, autotools-multilib.eclass is misleading as it
embeds the "unrelated" autotools-utils.eclass

So it seems currently that some are against this eclass, some are
against the whole idea and favour multilib-portage, some are against
using autotools-utils.eclass for this, ...
Some people are already committing the eclass version changes/fixes to
tree, some are filing bug reports about bugs caused by it, ...

It would be nice if people agreed but I guess that is not happening, so
i'll be pushing this eclass to tree under name 'multilib-minimal.eclass'
if I don't hear compelling arguments for not doing so, or in case you
push it before me

- Samuli


mgorny at gentoo

Feb 27, 2013, 12:13 PM

Post #23 of 30 (1537 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On Wed, 27 Feb 2013 15:01:51 +0200
Samuli Suominen <ssuominen [at] gentoo> wrote:

> On 24/02/13 16:17, hasufell wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> >> On 24/02/2013 11:06, Michał Górny wrote:
> >>> Then don't put 'autotools' in the name.
> >>
> >> +1
> >>
> >
> > That would be multilib-minimal.eclass then?
>
> Sounds good to me.
>
> > ABCD also suggested something else:
> > autotools-multilib.eclass -> autotools-utils-multilib.eclass
>
> This makes sense too, autotools-multilib.eclass is misleading as it
> embeds the "unrelated" autotools-utils.eclass
>
> So it seems currently that some are against this eclass, some are
> against the whole idea and favour multilib-portage, some are against
> using autotools-utils.eclass for this, ...
> Some people are already committing the eclass version changes/fixes to
> tree, some are filing bug reports about bugs caused by it, ...
>
> It would be nice if people agreed but I guess that is not happening, so
> i'll be pushing this eclass to tree under name 'multilib-minimal.eclass'
> if I don't hear compelling arguments for not doing so, or in case you
> push it before me

No, don't do it. Or at least wait till I clean up multilib-build a bit.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.94 KB)


pacho at gentoo

Feb 27, 2013, 12:15 PM

Post #24 of 30 (1531 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

El mié, 27-02-2013 a las 15:01 +0200, Samuli Suominen escribió:
> On 24/02/13 16:17, hasufell wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> >> On 24/02/2013 11:06, Michał Górny wrote:
> >>> Then don't put 'autotools' in the name.
> >>
> >> +1
> >>
> >
> > That would be multilib-minimal.eclass then?
>
> Sounds good to me.
>
> > ABCD also suggested something else:
> > autotools-multilib.eclass -> autotools-utils-multilib.eclass
>
> This makes sense too, autotools-multilib.eclass is misleading as it
> embeds the "unrelated" autotools-utils.eclass
>
> So it seems currently that some are against this eclass, some are
> against the whole idea and favour multilib-portage, some are against
> using autotools-utils.eclass for this, ...
> Some people are already committing the eclass version changes/fixes to
> tree, some are filing bug reports about bugs caused by it, ...
>
> It would be nice if people agreed but I guess that is not happening, so
> i'll be pushing this eclass to tree under name 'multilib-minimal.eclass'
> if I don't hear compelling arguments for not doing so, or in case you
> push it before me
>
> - Samuli
>
>

Probably the way to reach higher consensus would be to have an eclass
for supporting out of sources building and make other eclasses rely on
that code, that way people can use autotools-utils or use new eclass
"manually" as they prefer :/

Anyway I don't think autotools-utils includes so much changes :|
Attachments: signature.asc (0.19 KB)


hasufell at gentoo

Feb 27, 2013, 5:06 PM

Post #25 of 30 (1534 views)
Permalink
Re: New eclass: autotools-multilib-minimal [In reply to]

On 02/24/2013 11:39 PM, Samuli Suominen wrote:
> On 24/02/13 02:34, hasufell wrote:
>> Some people seem to feel uncomfortable with autotools-multilib, because
>> it depends on autotools-utils.
>>
>> Instead of arguing whether it makes sense or not I'd propose a similar
>> autotools related eclass.
>>
>> I also attach an example conversion of media-libs/libexif (the
>> maintainer wants to keep the changes minimal).
>> Effectively I am only (almost) changing the function names and not the
>> ebuild code.
>
> looks good, seems exactly what I wanted
>
>> Feel free to propose a different eclass name.
>
> whatever it will be, please make it shorter, like 'multiabi' maybe
>

I cleaned up some things.

1) eclass renamed to multilib-minimal.eclass
prepabisources() renamed to multilib_copy_sources()

2) if someone wants out-of-source builds he gotta handle that manually,
as in: not calling multilib_copy_sources and making sure that stuff like
ECONF_SOURCE is set correctly
(${BUILD_DIR} will be created unconditionally in src_configure anyway)

3) all autotools related code removed

4) Introduced a DISABLE_MULTILIB variable for use of portage-multilib,
which will disable all multilib related stuff. I am not sure if that's
what they want, but I heard something like that.
Tommy should comment on this.

In case this eclass will be deprecated at some point, conversion back to
normal will be trivial anyway.
Attachments: multilib-minimal.eclass (3.33 KB)
  libexif-0.6.21.ebuild.diff (1.52 KB)

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.