On 20 Mar 2017 20:35, Michał Górny wrote:
> Remove the parallel econf logic that adds a lot of complexity for minor
> gain. It results in the output from different configure scripts being
> mixed in the build log, making it unreadable. It causes econf to be run
> in a subshell which is a PMS violat
On Mon, 20 Mar 2017 20:35:52 +0100
Michał Górny wrote:
CCing maintainer
> Remove the parallel econf logic that adds a lot of complexity for minor
> gain. It results in the output from different configure scripts being
> mixed in the build log, making it unreadable. It causes econf to be run
> in
On Mon, 20 Mar 2017 20:35:51 +0100
Michał Górny wrote:
CCing maintainer
> The parallel econf code is used only with USE=static-libs, and even in
> that case provides negligible speed gain. At the same time, it adds
> a lot of complexity, causes the build logs to be unreadable mix of
> output fro
On Mon, 20 Mar 2017 22:19:16 +0100
Michał Górny wrote:
> On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> > On Mon, 20 Mar 2017 19:24:58 +0100
> > Michał Górny wrote:
> >
> > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > > What makes me wonder more are the propo
On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 19:24:58 +0100
> Michał Górny wrote:
>
> > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > What makes me wonder more are the proposed solutions: So far the
> > > only proposals I've seen are either inlin
On Mon, 20 Mar 2017 20:25:52 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
> > What makes me wonder more are the proposed solutions: So far the
> > only proposals I've seen are either inlining *all* the code or
> > moving *all* the code into an eclass. Having
On Mon, 20 Mar 2017 19:24:58 +0100
Michał Górny wrote:
> On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > What makes me wonder more are the proposed solutions: So far the
> > only proposals I've seen are either inlining *all* the code or
> > moving *all* the code into an eclass. Havin
Remove the parallel econf logic that adds a lot of complexity for minor
gain. It results in the output from different configure scripts being
mixed in the build log, making it unreadable. It causes econf to be run
in a subshell which is a PMS violation and can cause issues with some of
package mana
The parallel econf code is used only with USE=static-libs, and even in
that case provides negligible speed gain. At the same time, it adds
a lot of complexity, causes the build logs to be unreadable mix of
output from both configure scripts and violates PMS by calling econf
in parallel which can ca
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
> What makes me wonder more are the proposed solutions: So far the
> only proposals I've seen are either inlining *all* the code or
> moving *all* the code into an eclass. Having a quick look at
> autoconf, it seems to me an intermediate solution wo
On Mon, Mar 20, 2017 at 2:15 PM, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 13:40:51 -0400
> Mike Gilbert wrote:
>
>> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
>> wrote:
>> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
>> > global scope here. At least an 'ewarn "${FILE
On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> What makes me wonder more are the proposed solutions: So far the only
> proposals I've seen are either inlining *all* the code or moving *all*
> the code into an eclass. Having a quick look at autoconf, it seems to me
> an intermediate solu
On Mon, 20 Mar 2017 13:40:51 -0400
Mike Gilbert wrote:
> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
> wrote:
> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
> > only ' blah'.
>
> I cannot reproduce
On Mon, Mar 20, 2017 at 10:27 AM, William Hubbs wrote:
> Hi David,
>
> I'm curious, why the revbump?
>
> If all other eapis are staying in the eclass and the support is
> identical, you don't need to create a new eclass, and there is a lot
> less work involved in updating the ebuilds that inherit
On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier wrote:
> I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
> scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.
I cannot reproduce this behavior.
% emerge --version
Portage 2.3.5_p2 (python 3.5.3-final-0,
On Mon, 20 Mar 2017 15:12:43 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
> >> After the PMS change, we will have the same properties for DISTDIR,
> >> FILESDIR, WORKDIR, and S. Namely:
> >>
> >> - All four variables will be valid in src_* phases and in glo
Hi David,
I'm curious, why the revbump?
If all other eapis are staying in the eclass and the support is
identical, you don't need to create a new eclass, and there is a lot
less work involved in updating the ebuilds that inherit it. :-)
Thanks,
William
signature.asc
Description: Digital sign
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>> After the PMS change, we will have the same properties for DISTDIR,
>> FILESDIR, WORKDIR, and S. Namely:
>>
>> - All four variables will be valid in src_* phases and in global scope
>> - They will have a consistent value in the ebuild environmen
On Mon, 20 Mar 2017 10:49:40 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Mike Frysinger wrote:
>
> > obvious NAK until you sort out the open questions already raised
> > about the backwards breaking change you're trying to land in PMS.
>
> There are indeed some PMS patches pend
> On Mon, 20 Mar 2017, Mike Frysinger wrote:
> obvious NAK until you sort out the open questions already raised
> about the backwards breaking change you're trying to land in PMS.
There are indeed some PMS patches pending about DISTDIR, FILESDIR,
WORKDIR, and S, but I fail to see where they w
On 16 Mar 2017 10:38, Michał Górny wrote:
> Convert the usage of eblits in sys-devel/autoconf into an equivalent
> eclass. This makes the ebuilds more readable, more predictable and fixes
> compliance with stricter versions of the package manager (i.e. a future
> release of Portage).
obvious NAK u
21 matches
Mail list logo
