Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
-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
On Mon, Sep 8, 2008 at 4:03 PM, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 23:13 Mon 08 Sep , Ciaran McCreesh wrote: >> On Mon, 8 Sep 2008 14:33:50 -0700 >> Donnie Berkholz <[EMAIL PROTECTED]> wrote: >> > On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote: >> > > I personally agree with 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 >
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On 23:13 Mon 08 Sep , Ciaran McCreesh wrote: > On Mon, 8 Sep 2008 14:33:50 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote: > > > I personally agree with several others who have replied to this > > > thread. The reduction in lines of code/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 pgp6JqnSxvuC0.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, 8 Sep 2008 14:33:50 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote: > > I personally agree with several others who have replied to this > > thread. The reduction in lines of code/characters seems to > > introduce an uglier syntax which 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
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 pgp3XWqAWKVNO.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Ciaran McCreesh wrote: On Sun, 07 Sep 2008 12:46:45 -0400 "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote: The proposal is not designed to replace all cases. It's designed to replace the common 50%. I personally agree with several others who have replied to this thread. The reduction in lines 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
Alec Warner wrote: > Vaeth <[EMAIL PROTECTED]> wrote: > > > (Moreover, in most cases, > > this would not even save some characters, because the variable > > names would have to be much longer...) > > I don't think the variable names are really in scope (we can chose > them arbitrarily). But you 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
On Mon, Sep 8, 2008 at 1:56 PM, Vaeth <[EMAIL PROTECTED]> wrote: > Santiago M. Mola wrote: >> Vaeth <[EMAIL PROTECTED]> wrote: >> > >> > [...] The suggestion violates in an extreme way the golden design >> > rule that small changes in effect should require small changes in source. > [...] > >> Yes, 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: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Santiago M. Mola wrote: > Vaeth <[EMAIL PROTECTED]> wrote: > > > > [...] The suggestion violates in an extreme way the golden design > > rule that small changes in effect should require small changes in source. [...] > Yes, you're right. That would be really tedious and stupid... but > we're 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
-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-
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, Sep 8, 2008 at 1:58 AM, Santiago M. Mola <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner <[EMAIL PROTECTED]> wrote:
>>
>> Most obvious failure cases these days have build logs and the build
>> logs will specify what the configure command
>> was, so the only 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 \
>"[EMAIL PROTECTED]" \
>$(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: [EMAIL PROTECTED]
>
>
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner <[EMAIL PROTECTED]> wrote:
>
> Most obvious failure cases these days have build logs and the build
> logs will specify what the configure command
> was, so the only problematic area is looking at the ebuild to
> determine what will happen during 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 \
"[EMAIL PROTECTED]" \
$(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: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, Sep 8, 2008 at 1:07 AM, Vaeth <[EMAIL PROTECTED]> wrote: > >> Yes. And here another point should be brought up. This proposal should >> be wider and consider similar changes for the most common used >> operations on all phases. > > And in fact, the most common used operations on all phases 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
On Mon, Sep 8, 2008 at 9:48 AM, Vaeth <[EMAIL PROTECTED]> wrote: > > But it doesn't do this well, because it is incompatible with any other > case. Assume, for example, that you have an ebuild in this manner and > that for the new release or for a bugfix you need a small non-included > thing - then 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: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
> 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
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
On Sun, 7 Sep 2008, Ciaran McCreesh wrote:
> Vaeth <[EMAIL PROTECTED]> wrote:
> > Santiago M. Mola wrote:
> > > Alec Warner <[EMAIL PROTECTED]> wrote:
> > > > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> > > >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > > >>DEFAULT_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
On Sun, Sep 7, 2008 at 6:50 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Sun, 07 Sep 2008 12:46:45 -0400
> "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote:
>> > The proposal is not designed to replace all cases. It's designed to
>> > replace the common 50%.
>> >
>> I personally agree with 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: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sun, 07 Sep 2008 12:46:45 -0400 "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote: > > The proposal is not designed to replace all cases. It's designed to > > replace the common 50%. > > > I personally agree with several others who have replied to this > thread. The reduction in lines of code/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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Ciaran McCreesh wrote:
On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <[EMAIL PROTECTED]> wrote:
Santiago M. Mola wrote:
Alec Warner <[EMAIL PROTECTED]> wrote:
Thomas Anderson <[EMAIL PROTECTED]> wrote:
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
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
On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <[EMAIL PROTECTED]> wrote:
> Santiago M. Mola wrote:
> > Alec Warner <[EMAIL PROTECTED]> wrote:
> > > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> > >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > >>DEFAULT_SRC_CONFIGURE_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
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Santiago M. Mola wrote:
> Alec Warner <[EMAIL PROTECTED]> wrote:
> > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> >>DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
Essentially, this is the suggestion to replace the flexible shell 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
On Sat, Sep 6, 2008 at 10:10 PM, Ben de Groot <[EMAIL PROTECTED]> wrote:
> Alec Warner wrote:
>> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>Currently we have a lot of:
>>>src_configure() {
>>>econf $(use_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: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Alec Warner wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>> Hi,
>>Currently we have a lot of:
>>src_configure() {
>>econf $(use_enable dvdr) \
>>$(use_with ipv6 ssl) \
>>--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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 9:00 PM, Alec Warner <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>> Hi,
>>Currently we have a lot of:
>>src_configure() {
>>econf $(use_enable dvdr) \
>>$(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: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 12:00 PM, Alec Warner <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
>> Hi,
>>Currently we have a lot of:
>>src_configure() {
>>econf $(use_enable dvdr) \
>>$(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
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson <[EMAIL PROTECTED]> wrote:
> Hi,
>Currently we have a lot of:
>src_configure() {
>econf $(use_enable dvdr) \
>$(use_with ipv6 ssl) \
>--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
>
[gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
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
pgp7YUHyykivk.pgp
Description: PGP signature
