On 03/02/2013 04:07 PM, Michał Górny wrote:
> I don't think you should introduce workarounds in your eclass. I think
> multilib-build should be the place to do that.
Feel free to implement a solution. I think an explicit variable might
even be better instead of some magical checks which could caus
On Sat, 02 Mar 2013 03:50:11 +0100
hasufell wrote:
> On 02/28/2013 09:30 AM, Michał Górny wrote:
> >
> > Setting that variable would invalidate metadata cache.
> >
>
> different approach attached
I'm afraid you are doing too much, too fast and I simply can't follow.
I don't think you should
On 02/28/2013 09:30 AM, Michał Górny wrote:
>
> Setting that variable would invalidate metadata cache.
>
different approach attached
--- eclass/multilib-minimal.eclass
+++ eclass/multilib-minimal.eclass
@@ -18,12 +18,6 @@
#
# If you need generic install rules, use multilib_src_install_all func
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/28/2013 09:30 AM, Michał Górny wrote:
>
>> 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. To
On Thu, 28 Feb 2013 02:06:25 +0100
hasufell wrote:
> 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
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.
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
On Wed, 27 Feb 2013 15:01:51 +0200
Samuli Suominen 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
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 al
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 (t
-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-multil
On Sun, 24 Feb 2013 18:58:08 +0200
Samuli Suominen 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
On Sun, 24 Feb 2013 17:42:26 +0100
hasufell 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
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
On 02/24/2013 05:22 PM, Alexis Ballier wrote:
> On Sun, 24 Feb 2013 01:34:47 +0100
> hasufell 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
On Sun, 24 Feb 2013 16:53:02 +0100
Michał Górny 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 useles
On Sun, 24 Feb 2013 01:34:47 +0100
hasufell 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-multil
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 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 intr
On Sun, 24 Feb 2013 16:12:18 +0100
Pacho Ramos 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
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 pr
-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
> 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 e
On Sun, 24 Feb 2013 05:22:43 +0100
hasufell 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.eclas
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-mi
-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.
A
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 l
On Sun, 24 Feb 2013 05:22:43 +0100
hasufell 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.eclas
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:
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 chang
28 matches
Mail list logo