-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
> On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote:
>> I personally agree with several others who have replied to this thread.
>> The reduction in lines of code/characters seems to introduce an uglier
>> syntax which is hard
On Mon, Sep 8, 2008 at 4:03 PM, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> On 23:13 Mon 08 Sep , Ciaran McCreesh wrote:
>> On Mon, 8 Sep 2008 14:33:50 -0700
>> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>> > On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote:
>> > > I personally agree with sev
On 23:13 Mon 08 Sep , Ciaran McCreesh wrote:
> On Mon, 8 Sep 2008 14:33:50 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> > On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote:
> > > I personally agree with several others who have replied to this
> > > thread. The reduction in lines of code
On Mon, 8 Sep 2008 14:33:50 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote:
> > I personally agree with several others who have replied to this
> > thread. The reduction in lines of code/characters seems to
> > introduce an uglier syntax which i
On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote:
> I personally agree with several others who have replied to this thread.
> The reduction in lines of code/characters seems to introduce an uglier
> syntax which is harder to read with questionable benefits.
One of the great things about ebuil
Ciaran McCreesh wrote:
On Sun, 07 Sep 2008 12:46:45 -0400
"Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote:
The proposal is not designed to replace all cases. It's designed to
replace the common 50%.
I personally agree with several others who have replied to this
thread. The reduction in lines
Alec Warner wrote:
> Vaeth <[EMAIL PROTECTED]> wrote:
>
> > (Moreover, in most cases,
> > this would not even save some characters, because the variable
> > names would have to be much longer...)
>
> I don't think the variable names are really in scope (we can chose
> them arbitrarily).
But you c
On Mon, Sep 8, 2008 at 1:56 PM, Vaeth <[EMAIL PROTECTED]> wrote:
> Santiago M. Mola wrote:
>> Vaeth <[EMAIL PROTECTED]> wrote:
>> >
>> > [...] The suggestion violates in an extreme way the golden design
>> > rule that small changes in effect should require small changes in source.
> [...]
>
>> Yes,
Santiago M. Mola wrote:
> Vaeth <[EMAIL PROTECTED]> wrote:
> >
> > [...] The suggestion violates in an extreme way the golden design
> > rule that small changes in effect should require small changes in source.
[...]
> Yes, you're right. That would be really tedious and stupid... but
> we're luck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
> If you're just dealing with the default phases, it's not too hard to
> say in advance the exact command that will be executed.
If that's the case, why go so far as to define three new variables and
potentially put them out in
On Mon, Sep 8, 2008 at 1:58 AM, Santiago M. Mola <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner <[EMAIL PROTECTED]> wrote:
>>
>> Most obvious failure cases these days have build logs and the build
>> logs will specify what the configure command
>> was, so the only problem
On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner <[EMAIL PROTECTED]> wrote:
>
> Most obvious failure cases these days have build logs and the build
> logs will specify what the configure command
> was, so the only problematic area is looking at the ebuild to
> determine what will happen during executio
On Mon, Sep 8, 2008 at 1:07 AM, Vaeth <[EMAIL PROTECTED]> wrote:
>
>> Yes. And here another point should be brought up. This proposal should
>> be wider and consider similar changes for the most common used
>> operations on all phases.
>
> And in fact, the most common used operations on all phases
On Mon, Sep 8, 2008 at 9:48 AM, Vaeth <[EMAIL PROTECTED]> wrote:
>
> But it doesn't do this well, because it is incompatible with any other
> case. Assume, for example, that you have an ebuild in this manner and
> that for the new release or for a bugfix you need a small non-included
> thing - then
> Yes. And here another point should be brought up. This proposal should
> be wider and consider similar changes for the most common used
> operations on all phases.
And in fact, the most common used operations on all phases are
already covered: Namely, this is the default implementation of the p
On Monday 08 September 2008 08:48:23 Vaeth wrote:
> But it doesn't do this well
Those of us who have actually been using it say it does.
On Sun, 7 Sep 2008, Ciaran McCreesh wrote:
> Vaeth <[EMAIL PROTECTED]> wrote:
> > Santiago M. Mola wrote:
> > > Alec Warner <[EMAIL PROTECTED]> wrote:
> > > > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> > > >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > > >>DEFAULT
On Sun, Sep 7, 2008 at 6:50 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Sun, 07 Sep 2008 12:46:45 -0400
> "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote:
>> > The proposal is not designed to replace all cases. It's designed to
>> > replace the common 50%.
>> >
>> I personally agree with seve
On Sun, 07 Sep 2008 12:46:45 -0400
"Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote:
> > The proposal is not designed to replace all cases. It's designed to
> > replace the common 50%.
> >
> I personally agree with several others who have replied to this
> thread. The reduction in lines of code/cha
Ciaran McCreesh wrote:
On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <[EMAIL PROTECTED]> wrote:
Santiago M. Mola wrote:
Alec Warner <[EMAIL PROTECTED]> wrote:
Thomas Anderson <[EMAIL PROTECTED]> wrote:
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <[EMAIL PROTECTED]> wrote:
> Santiago M. Mola wrote:
> > Alec Warner <[EMAIL PROTECTED]> wrote:
> > > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> > >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > >>DEFAULT_SRC_CONFIGURE
Santiago M. Mola wrote:
> Alec Warner <[EMAIL PROTECTED]> wrote:
> > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> >>DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
Essentially, this is the suggestion to replace the flexible shell cod
On Sat, Sep 6, 2008 at 10:10 PM, Ben de Groot <[EMAIL PROTECTED]> wrote:
> Alec Warner wrote:
>> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>Currently we have a lot of:
>>>src_configure() {
>>>econf $(use_ena
Alec Warner wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>> Hi,
>>Currently we have a lot of:
>>src_configure() {
>>econf $(use_enable dvdr) \
>>$(use_with ipv6 ssl) \
>>
On Sat, Sep 6, 2008 at 9:00 PM, Alec Warner <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>> Hi,
>>Currently we have a lot of:
>>src_configure() {
>>econf $(use_enable dvdr) \
>>
On Sat, Sep 6, 2008 at 12:00 PM, Alec Warner <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>> Hi,
>>Currently we have a lot of:
>>src_configure() {
>>econf $(use_enable dvdr) \
>>
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
> Hi,
>Currently we have a lot of:
>src_configure() {
>econf $(use_enable dvdr) \
>$(use_with ipv6 ssl) \
>--wi
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly take
28 matches
Mail list logo
