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] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Vaeth]

Ciaran McCreesh wrote:
> 
> 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

No, this is exactly what ebuilds meant for: That the package manager
keeps track of your package, and possibly also recompiles it in case
of library upgrades. For this reason, ebuilds should essentially just
consist of the commands which you would also type in the shell - this
information *must* be provided (together with obviously some data like
package name, slot-requests, and an otional description), but essentially
that should be it.
If it is more work or requires more knowledge to write an ebuild, then
it is the ebuild concept which is defect.

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

[Bernd Steinhauser]

Vaeth wrote:
> Ciaran McCreesh wrote:
>> 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
> 
> No, this is exactly what ebuilds meant for: That the package manager
> keeps track of your package, and possibly also recompiles it in case
> of library upgrades. For this reason, ebuilds should essentially just
> consist of the commands which you would also type in the shell - this
> information *must* be provided (together with obviously some data like
> package name, slot-requests, and an otional description), but essentially
> that should be it.
> If it is more work or requires more knowledge to write an ebuild, then
> it is the ebuild concept which is defect.
> 
So in your opinion, a future eapi should make ebuilds look closer to this?
http://aur.archlinux.org/packages/mplayer/mplayer/PKGBUILD

Importare is a very useful and nice tool.
I don't understand, that Portage doesn't have something like that, yet.
(So they should consider doing something like that.)
When I was still using Gentoo, I did a lot of ebuilds for programs which 
I found out, that they don't work afterwards.
Using package.provide isn't really nice either, because it then isn't 
tracked.
With importare, I can first test it, and if it works, make an 
ebuild/exheres and install that.
If you do that, it will automatically upgrade the importare'd package 
and uninstall any leftovers, just like a normal update.

BTW, it is not a PM replacement, it is an addition.
You would be considered to be mad if you use importare for everything.

Regards,
Bernd

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.

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

[Steve Long]

Vaeth wrote:

> The point is that in contrast to shell code you need additional
> pre-knowledge to read or write it.
>
True.
 
>> 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.
>
Yes it's "extended syntax" if you like.
 
> The knowledge needed to write or read ebuilds should be kept
> as small as possible.

Agreed. This is similar to the "make it look like as much like a from-src
build as possible" argument. I would question just how much of a burden
this adds to the knowledge required to write an ebuild, however.

[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

[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 --]

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

[Steve Long]

Ben de Groot wrote:

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

Well the original patch used DEFAULT_CONFIG_ENABLE and DEFAULT_CONFIG_WITH
and didn't invoke any subshells. I'm not sure what the thinking behind
changing it was, unless it was a straight lift from paludis.

As for caps, that's kinda standard within ebuild-land if something crosses
functional boundaries, but I agree they're ugly ;) (In Bash, I'd only use
them for constants or env vars.)