Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Vaeth]

Santiago M. Mola wrote:
> Alec Warner <antarus@gentoo.org> wrote:
> > Thomas Anderson <gentoofan23@gentoo.org> wrote:
> >>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> >>                DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS

Essentially, this is the suggestion to replace the flexible shell code
by some static variables. Besides being less intuitive and less readable
(you have to know the meaning of all the variables to understand it)
it also works only for fixed cases, e.g. if it is only ./configure
(and not ./autogen.sh or something else) which has to be called,
and only if it has to be called exactly once in the main directory
For all other cases, either *everything* has to be done manually,
or you have to introduce even more variables to cover more cases.

Your second example shows no advantage either since you could just
have rewritten it by standard means anyway:

> src_compile() {
> 	local myconf="
> 		--sysconfdir=/etc/${PN}
> 		--without-xgrid
> 		--enable-pretty-print-stacktrace
> 		--enable-orterun-prefix-by-default
> 		--without-slurm"
> 
> 	if use threads; then
> 		myconf="${myconf}
> 			--enable-mpi-threads
> 			--with-progress-threads
> 	fi
> 
> 	econf ${myconf} \
> 		$(use_enable !nocxx mpi-cxx) \
> 		$(use_enable romio io-romio) \
> 		$(use_enable heterogeneous) \
> 		$(use_with pbs tm) \
> 		$(use_enable ipv6) \
> 	|| die "econf failed"
> 
> 	emake  || die "emake failed"
> }

With EAPI=2 you would probably do the above in src_configure which means
that you omit the last line anyway. Moreover, if you dislike using a
temporary variable and just want to collect options you could have
written it this way:

src_configure() {
	econf --sysconfdir=/etc/"${PN}" \
		--without-xgrid ... \
		--without-slurm \
		$(use threads && echo \
			--enable-mpi-threads \
			--with-progress-threads) \
		$(use_enable !nocxx mpi-cxx) ... \
		$(use_enable ipv6) \
	|| die "econf failed"
}

This is simply more intuitive and readable than your suggestion,
and moreover, this can also be used if in the "use threads" part
you have other options than --enable-* or --with-* (e.g. some --disable-*
or even more options in which case your suggestion would become a mess
more and more).

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> Santiago M. Mola wrote:
> > Alec Warner <antarus@gentoo.org> wrote:
> > > Thomas Anderson <gentoofan23@gentoo.org> wrote:
> > >>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > >>                DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
> 
> Essentially, this is the suggestion to replace the flexible shell code
> by some static variables. Besides being less intuitive and less
> readable (you have to know the meaning of all the variables to
> understand it) it also works only for fixed cases, e.g. if it is
> only ./configure (and not ./autogen.sh or something else) which has
> to be called, and only if it has to be called exactly once in the
> main directory For all other cases, either *everything* has to be
> done manually, or you have to introduce even more variables to cover
> more cases.

The proposal is not designed to replace all cases. It's designed to
replace the common 50%.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Marcus D. Hanwell]

Ciaran McCreesh wrote:
> On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
> Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>   
>> Santiago M. Mola wrote:
>>     
>>> Alec Warner <antarus@gentoo.org> wrote:
>>>       
>>>> Thomas Anderson <gentoofan23@gentoo.org> wrote:
>>>>         
>>>>>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
>>>>>                DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
>>>>>           
>> Essentially, this is the suggestion to replace the flexible shell code
>> by some static variables. Besides being less intuitive and less
>> readable (you have to know the meaning of all the variables to
>> understand it) it also works only for fixed cases, e.g. if it is
>> only ./configure (and not ./autogen.sh or something else) which has
>> to be called, and only if it has to be called exactly once in the
>> main directory For all other cases, either *everything* has to be
>> done manually, or you have to introduce even more variables to cover
>> more cases.
>>     
>
> 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/characters seems to introduce an uglier 
syntax which is harder to read with questionable benefits.

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Sun, 07 Sep 2008 12:46:45 -0400
"Marcus D. Hanwell" <cryos@gentoo.org> 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/characters seems to introduce
> an uglier syntax which is harder to read with questionable benefits.

Try using it for a few weeks. Once you're used to it it's considerably
nicer than going through and implementing pointless src_configures all
over the place...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Santiago M. Mola]

On Sun, Sep 7, 2008 at 6:50 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 07 Sep 2008 12:46:45 -0400
> "Marcus D. Hanwell" <cryos@gentoo.org> 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/characters seems to introduce
>> an uglier syntax which is harder to read with questionable benefits.
>
> Try using it for a few weeks. Once you're used to it it's considerably
> nicer than going through and implementing pointless src_configures all
> over the place...
>

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. Implementing it only for
src_{configure,compile} won't feel so useful as implementing similar
variables for most phases.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sun, 07 Sep 2008 12:46:45 -0400
> "Marcus D. Hanwell" <cryos@gentoo.org> 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/characters seems to introduce
>> an uglier syntax which is harder to read with questionable benefits.
> 
> Try using it for a few weeks. Once you're used to it it's considerably
> nicer than going through and implementing pointless src_configures all
> over the place...
> 

Nothing that couldn't be done using an eclass and a nicer syntax IMHO...

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

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 ebuilds is that they're very natural to 
write in most cases, if you can manage to build the program by hand. 
Raising this barrier of entry for questionable benefit seems like a bad 
idea. We don't need to make it any harder to begin contributing to 
Gentoo.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Mon, 8 Sep 2008 14:33:50 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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 harder to read with
> > questionable benefits.
> 
> One of the great things about ebuilds is that they're very natural to 
> write in most cases, if you can manage to build the program by hand. 
> Raising this barrier of entry for questionable benefit seems like a
> bad idea. We don't need to make it any harder to begin contributing
> to Gentoo.

So why are we making people know the exact ins and outs of
reimplementing default functions, complete with knowledge of whether or
not to use die, when all they need in most cases is to set a simple
variable instead?

What proportion of people do you think know whether or not you need a
die with econf or emake? How many user-written ebuilds out there
correctly install the right docs and don't try to install docs that
don't exist, deal with install parallelisation correctly and handle
error cases properly?

The DEFAULT_* variables make it *easier* to write packages because half
the time you don't need to arse around writing src_* functions. Every
src_* function written by someone is another place there can be a
non-obvious screwup.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

On 23:13 Mon 08 Sep     , Ciaran McCreesh wrote:
> On Mon, 8 Sep 2008 14:33:50 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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 harder to read with
> > > questionable benefits.
> > 
> > One of the great things about ebuilds is that they're very natural to 
> > write in most cases, if you can manage to build the program by hand. 
> > Raising this barrier of entry for questionable benefit seems like a
> > bad idea. We don't need to make it any harder to begin contributing
> > to Gentoo.
> 
> So why are we making people know the exact ins and outs of
> reimplementing default functions, complete with knowledge of whether or
> not to use die, when all they need in most cases is to set a simple
> variable instead?

This series of variables and syntaxes within them doesn't seem much 
simpler than functions. From what I understand, it also conflates 
multiple concepts into a single variable name (the function name, 
whether it's USE-dependent, and how the configure flag is passed).

> What proportion of people do you think know whether or not you need a 
> die with econf or emake? How many user-written ebuilds out there 
> correctly install the right docs and don't try to install docs that 
> don't exist, deal with install parallelisation correctly and handle 
> error cases properly?

You're right, following all of the policy takes work. What I'm talking 
about is an entry-level ebuild hack that just gets people in the door 
and is the reason a lot of people love Gentoo.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Alec Warner]

On Mon, Sep 8, 2008 at 4:03 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 23:13 Mon 08 Sep     , Ciaran McCreesh wrote:
>> On Mon, 8 Sep 2008 14:33:50 -0700
>> Donnie Berkholz <dberkholz@gentoo.org> 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 harder to read with
>> > > questionable benefits.
>> >
>> > One of the great things about ebuilds is that they're very natural to
>> > write in most cases, if you can manage to build the program by hand.
>> > Raising this barrier of entry for questionable benefit seems like a
>> > bad idea. We don't need to make it any harder to begin contributing
>> > to Gentoo.
>>
>> So why are we making people know the exact ins and outs of
>> reimplementing default functions, complete with knowledge of whether or
>> not to use die, when all they need in most cases is to set a simple
>> variable instead?
>
> This series of variables and syntaxes within them doesn't seem much
> simpler than functions. From what I understand, it also conflates
> multiple concepts into a single variable name (the function name,
> whether it's USE-dependent, and how the configure flag is passed).
>
>> What proportion of people do you think know whether or not you need a
>> die with econf or emake? How many user-written ebuilds out there
>> correctly install the right docs and don't try to install docs that
>> don't exist, deal with install parallelisation correctly and handle
>> error cases properly?
>
> You're right, following all of the policy takes work. What I'm talking
> about is an entry-level ebuild hack that just gets people in the door
> and is the reason a lot of people love Gentoo.

We are not making them use this syntax; nothing stops them using the other one.

-Alec

>
> --
> Thanks,
> Donnie
>
> Donnie Berkholz
> Developer, Gentoo Linux
> Blog: http://dberkholz.wordpress.com
>

[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20080908231325.0846cead@snowmobile, excerpted below, on  Mon, 08 Sep 2008
23:13:25 +0100:

> On Mon, 8 Sep 2008 14:33:50 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> 
>> One of the great things about ebuilds is that they're very natural to
>> write in most cases, if you can manage to build the program by hand.
>> Raising this barrier of entry for questionable benefit seems like a bad
>> idea. We don't need to make it any harder to begin contributing to
>> Gentoo.

Great point, Donnie.  One of the things I've appreciated about the ebuild 
format is how accessible it is... in comparison to say some spec file.  
Part of that of course is that it's right out there in the open, not tied 
up in some semi-transparent tarball, but part of it is certainly that 
it's reasonably close to simple bash, as well.

> So why are we making people know the exact ins and outs of
> reimplementing default functions, complete with knowledge of whether or
> not to use die, when all they need in most cases is to set a simple
> variable instead?
> 
> What proportion of people do you think know whether or not you need a
> die with econf or emake?

This is a valid point as well.  However, for a user simply concerned with 
getting a functional ebuild so the package is tracked by the PM as 
opposed to not (or manually tracking with package.provided), an extra die 
or two, or even the lack thereof, and the docs and stuff, don't matter as 
much as something easily understood and written with little more than 
knowledge of bash and what's easily cribbed from a few existing ebuilds 
used as samples.

These rather arbitrary vars do make sense to someone with a bit more 
knowledge, but are going to be about as opaque as the proper use of die, 
etc.  What's worse, they make the simple-case ebuilds more difficult to 
crib from for the user-sysadmin simply interested in getting a functional 
ebuild that allows the packaging system knowledge of what he's 
installing.  This sort of person is likely to write the ebuild, test it, 
and when it works, be done with it, regardless of its "correctness", and 
ideally with as little pre-supposed knowledge as possible.  They don't 
care about dies, but will care if they have to spend another half hour 
diving into docs to figure out how to effectively translate 
the .configure --with/etc stuff into the appropriate vars.

> The DEFAULT_* variables make it *easier* to write packages because half
> the time you don't need to arse around writing src_* functions. Every
> src_* function written by someone is another place there can be a
> non-obvious screwup.

That's true for the dev, certainly, but they do presuppose certain 
additional pre-knowledge that our user-sysadmin above won't have 
immediately.

What's more worrying from the perspective of that person is that while 
all these new vars are optional, if devs (with that pre-knowledge) start 
using them as easier, pretty soon that person above isn't going to have 
any easily accessible simple ebuilds to crib from any more.  It's not 
directly apparent that those vars hold what would be fed to .configure 
more or less directly, without knowledge of the package the ebuild is 
for.  In ordered to get that knowledge, the newbie ebuild writer will be 
forced to either investigate the packages he's cribbing from the ebuilds 
of, or look up the PM/PMS/ebuild documentation.

At least with eclasses, once one knows about inherit (a pretty simple 
concept once people start looking at ebuilds), it's standard bash 
functionality and easy enough to lookup what those arbitrary vars 
actually do.  If we implement this, it's going to be locked away in the 
PM somewhere not so easily accessible.  Additional specialized knowledge 
will be necessary.

(Hmm... this argument went other than I intended.  I was planning to 
point out that usage of the vars was optional, and that our user-sysadmin 
wouldn't have to use them if they didn't want to... but then as I wrote, 
I realized it may be optional, but that doesn't help much if all the 
simple ebuilds he finds to crib from end up using the pre-knowledge 
required vars, leaving him nothing simple to crib from without that 
knowledge.  The accessibility level will have been reduced if this 
happens.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

On Mon, 8 Sep 2008 23:20:15 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> > What proportion of people do you think know whether or not you need
> > a die with econf or emake?
> 
> This is a valid point as well.  However, for a user simply concerned
> with getting a functional ebuild so the package is tracked by the PM
> as opposed to not (or manually tracking with package.provided), an
> extra die or two, or even the lack thereof, and the docs and stuff,
> don't matter as much as something easily understood and written with
> little more than knowledge of bash and what's easily cribbed from a
> few existing ebuilds used as samples.

People shouldn't be writing ebuilds to do that at all. They should be
using a package manager provided tool that lets them keep track of
ebuild-less packages in a way that integrates properly with everything
else.

> What's more worrying from the perspective of that person is that
> while all these new vars are optional, if devs (with that
> pre-knowledge) start using them as easier, pretty soon that person
> above isn't going to have any easily accessible simple ebuilds to
> crib from any more.

Sure they will. There'll still be a significant number of ebuilds that
fall somwwhere between "easy enough to handle with the defaults" and
"horrid complex mess".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20080909003848.7bb5bbca@snowmobile, excerpted below, on  Tue, 09 Sep 2008
00:38:48 +0100:

> People shouldn't be writing ebuilds to do that at all. They should be
> using a package manager provided tool that lets them keep track of
> ebuild-less packages in a way that integrates properly with everything
> else.

I did mention package.provided, which is your PM provided tool... but 
there's some serious negatives to doing it that way, including the lack 
of an uninstall, package manifest, record of CFLAGS and etc used, all as 
automatically provided by the PM for the relatively low cost of a 
rudimentary ebuild.  It doesn't take much of a user-sysadmin to recognize 
at least /some/ of those merits and thus not be satisfied with bypassing 
them.  No familiarity with Gentoo is needed for that recognition, tho it 
might help in the recognition it's actually (more easily) possible for a 
mere human to implement on Gentoo, as opposed to a specfile based 
distribution, say.

As Donnie said in his post made while I was composing mine, it's the 
"entry level ebuild hack that just gets people in the door and is the 
reason a lot of people love Gentoo."

I'm certainly one of them.  I loved being able to jump right in, and 
while I've certainly progressed in understanding and ability since then, 
that accessibility, the openness of the entire Gentoo system including  
the ebuilds, continues to be one of the primary distinctions of Gentoo 
that holds me here; one of the biggest reasons it seems to "just fit" so 
much better than most other distributions, despite the (comparatively 
minor) hassles of continually updating from source.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Tue, 9 Sep 2008 00:58:52 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
> 20080909003848.7bb5bbca@snowmobile, excerpted below, on  Tue, 09 Sep
> 2008 00:38:48 +0100:
> > People shouldn't be writing ebuilds to do that at all. They should
> > be using a package manager provided tool that lets them keep track
> > of ebuild-less packages in a way that integrates properly with
> > everything else.
> 
> I did mention package.provided, which is your PM provided tool...

If you consider package.provided to be your package manager provided
tool, you need a much better package manager. Paludis has 'importare'
for tracking (with full uninstall, upgrade, slotting and dependency
handling capabilities) manually built packages. I assume Pkgcore has
something similar.

> As Donnie said in his post made while I was composing mine, it's the 
> "entry level ebuild hack that just gets people in the door and is the 
> reason a lot of people love Gentoo."

Having to write an ebuild just to install something in a package manager
friendly way and be able to uninstall it cleanly later is a defect, not
a feature.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20080909020645.73288af9@snowmobile, excerpted below, on  Tue, 09 Sep 2008
02:06:45 +0100:

> If you consider package.provided to be your package manager provided
> tool, you need a much better package manager. Paludis has 'importare'
> for tracking (with full uninstall, upgrade, slotting and dependency
> handling capabilities) manually built packages. I assume Pkgcore has
> something similar.

<the light dawns> Nice toy indeed, both for users and for developers 
wanting to get tabs on everything a new package is doing that affects the 
system, pre-ebuild-creation! =:^)

> Having to write an ebuild just to install something in a package manager
> friendly way and be able to uninstall it cleanly later is a defect, not
> a feature.

Impressively stated, but it still doesn't get past the simple open 
accessibility bit, letting the user-sysadmin do simple real-time 
modifications of how the package appears on and interacts with the 
individual system.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Steve Long]

Duncan wrote:

> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
>> Having to write an ebuild just to install something in a package manager
>> friendly way and be able to uninstall it cleanly later is a defect, not
>> a feature.
>
I've always rather liked that I can tell someone in -dev-help or -chat "If
you can build it from source, it's simple to make an ebuild. A lot of the
time you don't even need anything more than a few bash variables." So in
that sense I consider asking someone to do a little bit to be a good thing,
since it gets them over the first hurdle for contributing (and gives them a
Gentoo buzz.)
 
> Impressively stated, but it still doesn't get past the simple open
> accessibility bit, letting the user-sysadmin do simple real-time
> modifications of how the package appears on and interacts with the
> individual system.
>
I agree with the spirit of what you're saying. Taking the detail from your
other post:
 
>  it may be optional, but that doesn't help much if all the 
> simple ebuilds he finds to crib from end up using the pre-knowledge 
> required vars, leaving him nothing simple to crib from without that 
> knowledge.  The accessibility level will have been reduced if this 
> happens.

Yeah, but I don't think this would become the overriding method. Even if it
did, in terms of what developers, or indeed automated tools, produce, the
old method would, of necessity, always be allowed, and should be documented
in the "stages of an ebuild" part of a devmanual. Understanding of the
classic method is _required_ to make use of the declarative one, which is
just syntactic sugar for the classic econf/configure parameters.

(I still think the original patch is better, ofc ;)

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Arun Raghavan]

-----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 harder to read with questionable benefits.
> 
> One of the great things about ebuilds is that they're very natural to 
> write in most cases, if you can manage to build the program by hand. 
> Raising this barrier of entry for questionable benefit seems like a bad 
> idea. We don't need to make it any harder to begin contributing to 
> Gentoo.

+42

- -- Arun
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjKqLgACgkQ+Vqt1inD4uwD9ACfXJSvMQ2Xsj+IlXz9F3QrgKiC
dSMAoKEPhM1KlL35fE7uxc6DZHegzIcW
=qTCS
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Vaeth]

Santiago M. Mola wrote:
> Vaeth <vaeth@mathematik.uni-wuerzburg.de> 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 lucky, and EAPI-2 introduced the 'default' function. So if you
> need to do a small change not covered by this method, you just define
> the phase, make the little change, and then call the 'default'
> function. Clean and simple.

How does this "little change" look like if you have to call ./autogen.sh
instead of ./configure?  Or if you want to call a second ./configure
in some subdirectory with the same options but one option changed?

These are just some examples, I hope that the point becomes clear:
You simply cannot cover all natural modifications which might be
necessary unless you really can access the commands themselves;
and for this reason it is wise IMHO to have default functions which are
as short as possible (and which are in particular not dealing with
complex implicit array arguments).

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Santiago M. Mola]

On Mon, Sep 8, 2008 at 1:56 PM, Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> Santiago M. Mola wrote:
>> Vaeth <vaeth@mathematik.uni-wuerzburg.de> 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 lucky, and EAPI-2 introduced the 'default' function. So if you
>> need to do a small change not covered by this method, you just define
>> the phase, make the little change, and then call the 'default'
>> function. Clean and simple.
>
> How does this "little change" look like if you have to call ./autogen.sh
> instead of ./configure?

Most of the time you don't call autogen.sh, but eautoreconf. And when
you have to call ./autogen.sh you usually do it in src_unpack (or
src_prepare if it's introduced in EAPI-2).

> Or if you want to call a second ./configure
> in some subdirectory with the same options but one option changed?

This is not a "small change" that happens on any package too often (if
ever). For such cases you can define  a custom
src_configure/src_compile which fits your needs.

>
> These are just some examples, I hope that the point becomes clear:
> You simply cannot cover all natural modifications which might be
> necessary unless you really can access the commands themselves;

You can access the commands themselves,I think no one said ever in
this thread that use_with, use_enable or econf are going to be
deprecated.


Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Vaeth]

Alec Warner wrote:
> Vaeth <vaeth@mathematik.uni-wuerzburg.de> 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 cannot choose them much smaller unless you want to decrease
readability even more.

> I disagree with less readable; it is less intuitive

The point is that in contrast to shell code you need additional
pre-knowledge to read or write it.

> the syntax looks fine and the syntax is in fact still bash.

I do not want to start a discussion now whether this is
implicit semantic or sort of an extended syntax - it depends on the point
of view. But in any case it involves new (and actually redundant)
"keywords" in the ebuild.

> However, ebuilds are already
> sufficiently complicated by eclass inheritance that reading
> many ebuilds is already difficult

This is the point. For certain very specialized eclasses like kde or qt
this might be inavoidable, but one should strive to minimize these things
as much as possible. So an idea how to go into the *opposite* direction
is what is actually needed.

> and I think this extension does not make that significantly worse.

"because we made some mistakes anyway let us make even more..."

> Arguing about intentions is not really a compelling argument.  Spec

It is, if something does not satisfy (anymore) what is supposed to do.

> files have more than magic variables too; many have
> similar constructs to ebuilds (postinst and prerm phases, file
> manifests, etc.)  Specfiles and ebuilds are more alike than different.

Yes, meanwhile specfiles and ebuilds are very similar which is really
a problem: It is not accidental that many users of other distributions
prefer to install into /usr/local instead of writing rpms - most users
do not want to learn a specification. It is fatal if ebuilds go the
same road. The knowledge needed to write or read ebuilds should be kept
as small as possible.

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Vaeth]

On Sun, 7 Sep 2008, Ciaran McCreesh wrote:
> Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> > Santiago M. Mola wrote:
> > > Alec Warner <antarus@gentoo.org> wrote:
> > > > Thomas Anderson <gentoofan23@gentoo.org> wrote:
> > > >>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > > >>                DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
> > 
> > Essentially, this is the suggestion to replace the flexible shell code
> > by some static variables. [...]
> > For all other cases, either *everything* has to be
> > done manually, or you have to introduce even more variables to cover
> > more cases.
> 
> The proposal is not designed to replace all cases. It's designed to
> replace the common 50%.

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 this means that you have to rewrite the ebuild almost
completely. The suggestion violates in an extreme way the golden design
rule that small changes in effect should require small changes in source.
Moreover, a second syntax is introduced which everybody has learn,
although it could be done as easily by the standard commands.

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[David Leverton]

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.

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Santiago M. Mola]

On Mon, Sep 8, 2008 at 9:48 AM, Vaeth <vaeth@mathematik.uni-wuerzburg.de> 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 this means that you have to rewrite the ebuild almost
> completely. The suggestion violates in an extreme way the golden design
> rule that small changes in effect should require small changes in source.
> Moreover, a second syntax is introduced which everybody has learn,
> although it could be done as easily by the standard commands.
>
>

Yes, you're right. That would  be really tedious and stupid... but
we're lucky, and EAPI-2 introduced the 'default' function. So if you
need to do a small change not covered by this method, you just define
the phase, make the little change, and then call the 'default'
function. Clean and simple.

In any case, I guess people are not considering this change for
EAPI-2. I think we'll come up with a more extense proposal which could
be targeted for EAPI-3.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Vaeth]

> 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 phase.
Any change from this is not so common and should therefore be based on
writing the function. Saving here some characters for typing the
function header means to save at the wrong place by making everything
less readable and less maintainable. (Moreover, in most cases,
this would not even save some characters, because the variable
names would have to be much longer...)

Actually, too many variables with a predefined meaning are used in
ebuilds already now. The original intention of ebuilds was that -
in contrast to .spec-files or other stuff which are some sort of
extended database - it should be simple pure shell code which everybody
can easily read or write without filling in magic data.
Things like WANT_AUTOMAKE=1.8 already violate this rule, but it seems
hard to avoid it here, because IIRC there is no "src_depend()" function
where the calculation of the dependencies could be done in a consistent
manner. But the rule should not be violated without any serious need:
If ebuilds consist only in setting magic variables, you can use .spec
as well.

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Alec Warner]

On Mon, Sep 8, 2008 at 1:07 AM, Vaeth <vaeth@mathematik.uni-wuerzburg.de> 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 are
> already covered: Namely, this is the default implementation of the phase.
> Any change from this is not so common and should therefore be based on
> writing the function. Saving here some characters for typing the
> function header means to save at the wrong place by making everything
> less readable and less maintainable. (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).

I disagree with less readable; it is less intuitive to see what is
happening because there
is an abstraction; but the readability of the code is not impacted;
the syntax looks fine and the syntax
is in fact still bash.  We must make trade-offs between abstractions
and intuition and we should strive to make
our abstractions as intuitive as possible and I think we have mostly
succeeded in doing so in a variety of cases (and we
have certainly failed in others.)

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 execution.  Arguably having
an ebuildshell would assist here.  However, ebuilds are already
sufficiently complicated by eclass inheritance that reading
many ebuilds is already difficult and I think this extension does not
make that significantly worse.  Luckily the proposal does not
require this syntax to be used (and there is no real reason to prevent
the old syntax at this time; nor has anyone suggested we do so).

At best, the proposal entails a few lines in each PM that allow ebuild
authors to make simpler ebuilds.  I think this is a big plus as we can
reduce mistakes involving line continuation and reduce ebuild size.



>
> Actually, too many variables with a predefined meaning are used in
> ebuilds already now. The original intention of ebuilds was that -
> in contrast to .spec-files or other stuff which are some sort of
> extended database - it should be simple pure shell code which everybody
> can easily read or write without filling in magic data.
> Things like WANT_AUTOMAKE=1.8 already violate this rule, but it seems
> hard to avoid it here, because IIRC there is no "src_depend()" function
> where the calculation of the dependencies could be done in a consistent
> manner. But the rule should not be violated without any serious need:
> If ebuilds consist only in setting magic variables, you can use .spec
> as well.
>
>

Arguing about intentions is not really a compelling argument.  Spec
files have more than magic variables too; many have
similar constructs to ebuilds (postinst and prerm phases, file
manifests, etc.)  Specfiles and ebuilds are more alike than different.

-Alec

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Santiago M. Mola]

On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner <antarus@gentoo.org> 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 execution.  Arguably having
> an ebuildshell would assist here.  However, ebuilds are already
> sufficiently complicated by eclass inheritance that reading
> many ebuilds is already difficult and I think this extension does not
> make that significantly worse.

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. Default phases
are well-defined in PMS. So you can look at them to see what will
happend if you define some variable.

For example, for the proposed arguments for src_configure, a
definition would be something like this (taken from Exherbo, just
pretend it says USE instead OPTION and you're done):
    default_src_configure()
    {
        if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
            econf \
                "${DEFAULT_SRC_CONFIGURE_PARAMS[@]}" \
                $(for s in "${DEFAULT_SRC_CONFIGURE_OPTION_ENABLES}" ; do \
                    option_enable ${s} ; \
                done ) \
                $(for s in "${DEFAULT_SRC_CONFIGURE_OPTION_WITHS}" ; do \
                    option_with ${s} ; \
                done )
        fi
    }

It's quite straightforward.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Alec Warner]

On Mon, Sep 8, 2008 at 1:58 AM, Santiago M. Mola <coldwind@gentoo.org> wrote:
> On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner <antarus@gentoo.org> 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 execution.  Arguably having
>> an ebuildshell would assist here.  However, ebuilds are already
>> sufficiently complicated by eclass inheritance that reading
>> many ebuilds is already difficult and I think this extension does not
>> make that significantly worse.
>
> 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. Default phases
> are well-defined in PMS. So you can look at them to see what will
> happend if you define some variable.

The point is that it is not in the ebuild; you need to look it
up...unless you have all the default functions memorized? :)

>
> For example, for the proposed arguments for src_configure, a
> definition would be something like this (taken from Exherbo, just
> pretend it says USE instead OPTION and you're done):
>    default_src_configure()
>    {
>        if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
>            econf \
>                "${DEFAULT_SRC_CONFIGURE_PARAMS[@]}" \
>                $(for s in "${DEFAULT_SRC_CONFIGURE_OPTION_ENABLES}" ; do \
>                    option_enable ${s} ; \
>                done ) \
>                $(for s in "${DEFAULT_SRC_CONFIGURE_OPTION_WITHS}" ; do \
>                    option_with ${s} ; \
>                done )
>        fi
>    }
>
> It's quite straightforward.
>
> Regards,
> --
> Santiago M. Mola
> Jabber ID: cooldwind@gmail.com
>
>

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Mike Auty]

-----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 the main variable area?  If we've got
default_src_compile defined, we could do the following:

src_compile() {
	default_conf="$(use_with blah)
                      $(use_enable flibble)"
	default_src_compile
}

It then doesn't require *any* additional changes (except maybe to give
default_src_compile a well known variable name like $default_conf).
This is then only a single variable, and no more difficult to remember
than some of the eutils function names, and just as easy to look up.

It seems to allow the maximum flexibility, with the minimum changes to
package managers (assuming the defaults get into EAPI-2).

Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjE8vsACgkQu7rWomwgFXomRACgnvJZPSWEaSls4Fd+cy3T1cF5
UWQAoJ9fnZ82v5r2S/oz6GBo5Ot8iC9a
=pgRO
-----END PGP SIGNATURE-----

[gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

Hi,
	Currently we have a lot of:
		src_configure() {
			econf $(use_enable dvdr) \
				$(use_with ipv6 ssl) \
				--with-system-zlib
		}
	
	Introducing(Idea shamelessly taken from Exherbo):
		DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
		DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS

	The code from above could be rewritten like so:

	DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
	DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
	DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )

	That's much simpler. 

	Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to 
	append parameters to emake like so:

		src_compile() {
			emake buildtarget
		}

	which would be replaced by:
		DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )

	This was originally proposed in bug #230725[1]

Regards,
Thomas

[1] https://bugs.gentoo.org/show_bug.cgi?id=230725

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Alec Warner]

On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
> Hi,
>        Currently we have a lot of:
>                src_configure() {
>                        econf $(use_enable dvdr) \
>                                $(use_with ipv6 ssl) \
>                                --with-system-zlib
>                }
>
>        Introducing(Idea shamelessly taken from Exherbo):
>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
>                DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
>
>        The code from above could be rewritten like so:
>
>        DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
>        DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
>        DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
>
>        That's much simpler.

It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?

>
>        Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to
>        append parameters to emake like so:
>
>                src_compile() {
>                        emake buildtarget
>                }
>
>        which would be replaced by:
>                DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )
>
>        This was originally proposed in bug #230725[1]
>
> Regards,
> Thomas
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=230725
>

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Alec Warner]

On Sat, Sep 6, 2008 at 12:00 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
>> Hi,
>>        Currently we have a lot of:
>>                src_configure() {
>>                        econf $(use_enable dvdr) \
>>                                $(use_with ipv6 ssl) \
>>                                --with-system-zlib
>>                }
>>
>>        Introducing(Idea shamelessly taken from Exherbo):
>>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
>>                DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
>>
>>        The code from above could be rewritten like so:
>>
>>        DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
>>        DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
>>        DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
>>
>>        That's much simpler.
>
> It saves you 1 line and reduces readability and intuitiveness by a
> fair margin; how is it simpler?
>

errr s/1/2/ s/line/lines/ :/

>>
>>        Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to
>>        append parameters to emake like so:
>>
>>                src_compile() {
>>                        emake buildtarget
>>                }
>>
>>        which would be replaced by:
>>                DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )
>>
>>        This was originally proposed in bug #230725[1]
>>
>> Regards,
>> Thomas
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=230725
>>
>

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Santiago M. Mola]

On Sat, Sep 6, 2008 at 9:00 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
>> Hi,
>>        Currently we have a lot of:
>>                src_configure() {
>>                        econf $(use_enable dvdr) \
>>                                $(use_with ipv6 ssl) \
>>                                --with-system-zlib
>>                }
>>
>>        Introducing(Idea shamelessly taken from Exherbo):
>>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
>>                DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
>>
>>        The code from above could be rewritten like so:
>>
>>        DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
>>        DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
>>        DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
>>
>>        That's much simpler.
>
> It saves you 1 line and reduces readability and intuitiveness by a
> fair margin; how is it simpler?
>

In the given example it's not a big deal. However, when you're dealing
with more arguments it simplifies things.

For example, this (based on an existing ebuild, but simplified a bit
for brevity):

--------------------------
src_compile() {
	local myconf="
		--sysconfdir=/etc/${PN}
		--without-xgrid
		--enable-pretty-print-stacktrace
		--enable-orterun-prefix-by-default
		--without-slurm"

	if use threads; then
		myconf="${myconf}
			--enable-mpi-threads
			--with-progress-threads
	fi

	econf ${myconf} \
		$(use_enable !nocxx mpi-cxx) \
		$(use_enable romio io-romio) \
		$(use_enable heterogeneous) \
		$(use_with pbs tm) \
		$(use_enable ipv6) \
	|| die "econf failed"

	emake  || die "emake failed"
}
--------------------------

becomes

--------------------------
SRC_DEFAULT_CONFIGURE_WITHS=( "pbs tm" "ipv6" "threads progress-threads"
SRC_DEFAULT_CONFIGURE_ENABLES=(
    "cxx mpi-cxx"
    "romio io-romio"
    "heterogeneous"
    "threads mpi-threads"
SRC_DEFAULT_CONFIGURE_EXTRA_PARAMS=(
    --sysconfdir=/etc/${PN}
    --without-xgrid
    --enable-pretty-print-stacktrace
    --enable-orterun-prefix-by-default
    --without-slurm )
--------------------------

You save some lines, but also you keep out all the use_* calls with
their backslashes, myconf=$myconf crap, econf/emake || die...

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Alec Warner wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
>> Hi,
>>        Currently we have a lot of:
>>                src_configure() {
>>                        econf $(use_enable dvdr) \
>>                                $(use_with ipv6 ssl) \
>>                                --with-system-zlib
>>                }
>>
>>        Introducing(Idea shamelessly taken from Exherbo):
>>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
>>                DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
>>
>>        The code from above could be rewritten like so:
>>
>>        DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
>>        DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
>>        DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
>>
>>        That's much simpler.
> 
> It saves you 1 line and reduces readability and intuitiveness by a
> fair margin; how is it simpler?

It may be 2 lines less, but it is 42 characters more.
Plus, I dislike caps. :-p



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Santiago M. Mola]

On Sat, Sep 6, 2008 at 10:10 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> Alec Warner wrote:
>> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
>>> Hi,
>>>        Currently we have a lot of:
>>>                src_configure() {
>>>                        econf $(use_enable dvdr) \
>>>                                $(use_with ipv6 ssl) \
>>>                                --with-system-zlib
>>>                }
>>>
>>>        Introducing(Idea shamelessly taken from Exherbo):
>>>                DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
>>>                DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
>>>
>>>        The code from above could be rewritten like so:
>>>
>>>        DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
>>>        DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
>>>        DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
>>>
>>>        That's much simpler.
>>
>> It saves you 1 line and reduces readability and intuitiveness by a
>> fair margin; how is it simpler?
>
> It may be 2 lines less, but it is 42 characters more.
> Plus, I dislike caps. :-p

In the example I posted it's 339 characters less. Almost half of the
original ;-)

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com