-----BEGIN PGP SIGNED MESSAGE-----
On 02/24/2013 03:57 PM, MichaÅ‚ GÃ³rny wrote: > On Sun, 24 Feb 2013 05:22:43 +0100 hasufell <firstname.lastname@example.org>
>> Before people start asking I should explain why I started this:
>> 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
> 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
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/
-----END PGP SIGNATURE-----