[gentoo-dev] src_configure

[gentoo-dev] src_configure

[Sven Wegener]

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

Hi all!

I'm writing this mail to bring you a thought we had over on freenode in
the #gentoo-portage channel. We would like to split up src_compile. The
new src_configure should just do the econf part and src_compile should
do the emake part. This represents the general 3-step[1] installation in
a much better way.

Regards,
Sven

[1] ./configure && make && make install

-- 
Sven Wegener
Gentoo Developer
http://www.gentoo.org/

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

Re: [gentoo-dev] src_configure

[Aron Griffis]

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

Sven Wegener wrote:	[Wed Jul 06 2005, 08:04:04PM EDT]
> I'm writing this mail to bring you a thought we had over on freenode
> in the #gentoo-portage channel. We would like to split up
> src_compile. The new src_configure should just do the econf part and
> src_compile should do the emake part. This represents the general
> 3-step[1] installation in a much better way.

This would be great in that it would be possible to do:

    ebuild blah.ebuild configure

then change to the directory and work on it.  But the other side of
the coin is that you're talking about a LOT of ebuild changes, right?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] src_configure

[Diego 'Flameeyes' Pettenò]

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

On Thursday 07 July 2005 02:04, Sven Wegener wrote:
> We would like to split up src_compile. The
> new src_configure should just do the econf part and src_compile should
> do the emake part.
That will be very very interesting but... but not everything uses ./configure, 
so we should add a bunch of dummy src_configure, and a call to econf || die 
"" for those packages not fixed to use that will return a bunch of erroneous 
packages not compiling.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

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

Re: [gentoo-dev] src_configure

[Sven Wegener]

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

On Wed, Jul 06, 2005 at 08:14:55PM -0400, Aron Griffis wrote:
> Sven Wegener wrote:	[Wed Jul 06 2005, 08:04:04PM EDT]
> > I'm writing this mail to bring you a thought we had over on freenode
> > in the #gentoo-portage channel. We would like to split up
> > src_compile. The new src_configure should just do the econf part and
> > src_compile should do the emake part. This represents the general
> > 3-step[1] installation in a much better way.
> 
> This would be great in that it would be possible to do:
> 
>     ebuild blah.ebuild configure
> 
> then change to the directory and work on it.  But the other side of
> the coin is that you're talking about a LOT of ebuild changes, right?

Yes, but please see my EBUILD_FORMAT mail on how we'll provide backward
compatibility. It boils down to set EBUILD_FORMAT to the right value and
portage knows that the ebuild uses src_configure in addition to
src_compile. As we need to touch ebuilds for the src_configure change we
can also add the EBUILD_FORMAT variable in one go. If EBUILD_FORMAT is
unset, just use old behaviour.

Sven

-- 
Sven Wegener
Gentoo Developer
http://www.gentoo.org/



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

Re: [gentoo-dev] src_configure

[Jonathan Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
> On Thursday 07 July 2005 02:04, Sven Wegener wrote:
> 
>>We would like to split up src_compile. The
>>new src_configure should just do the econf part and src_compile should
>>do the emake part.
> 
> That will be very very interesting but... but not everything uses ./configure, 
> so we should add a bunch of dummy src_configure, and a call to econf || die 
> "" for those packages not fixed to use that will return a bunch of erroneous 
> packages not compiling.
> 

you could simply make the default:

src_configure() {
	[ -f ./configure ] && econf || die
}

- --

smithj

Gentoo Developer
[ desktop stuff && netmon && documentation ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzHcJl5AvwDPiUowRAqeFAJwIxve3a/X5BnlSBOxfv/Ac2lMAaACg30Pg
62/3CVfdiHVSppJfEe73DsY=
=lK9Q
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Mike Frysinger]

On Wednesday 06 July 2005 08:27 pm, Jonathan Smith wrote:
> you could simply make the default:
>
> src_configure() {
> 	[ -f ./configure ] && econf || die
> }

well you cant because then die would be called if ./configure isnt a file but 
i think that's irrelevant to the point you're trying to make ;)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Joshua Baergen]

Jonathan Smith wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Diego 'Flameeyes' Pettenò wrote:
>  
>
>>On Thursday 07 July 2005 02:04, Sven Wegener wrote:
>>
>>    
>>
>>>We would like to split up src_compile. The
>>>new src_configure should just do the econf part and src_compile should
>>>do the emake part.
>>>      
>>>
>>That will be very very interesting but... but not everything uses ./configure, 
>>so we should add a bunch of dummy src_configure, and a call to econf || die 
>>"" for those packages not fixed to use that will return a bunch of erroneous 
>>packages not compiling.
>>
>>    
>>
>
>you could simply make the default:
>
>src_configure() {
>	[ -f ./configure ] && econf || die
>}
>
>- --
>
>smithj
>
>Gentoo Developer
>[ desktop stuff && netmon && documentation ]
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCzHcJl5AvwDPiUowRAqeFAJwIxve3a/X5BnlSBOxfv/Ac2lMAaACg30Pg
>62/3CVfdiHVSppJfEe73DsY=
>=lK9Q
>-----END PGP SIGNATURE-----
>  
>
By order of operations that won't work...I think you'll have to do if/then.

if [ -f ./configure ]
then
    econf || die
fi

But that's a possible solution for sure.  It does introduce a lot of 
ebuild editing for those ebuilds doing special conf stuff though.

Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Diego 'Flameeyes' Pettenò]

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

On Thursday 07 July 2005 02:27, Jonathan Smith wrote:
> src_configure() {
> 	[ -f ./configure ] && econf || die
> }
I'm not still convinced about this.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

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

Re: [gentoo-dev] src_configure

[Joshua Baergen]

Jonathan Smith wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Diego 'Flameeyes' Pettenò wrote:
>  
>
>>On Thursday 07 July 2005 02:04, Sven Wegener wrote:
>>
>>    
>>
>>>We would like to split up src_compile. The
>>>new src_configure should just do the econf part and src_compile should
>>>do the emake part.
>>>      
>>>
>>That will be very very interesting but... but not everything uses ./configure, 
>>so we should add a bunch of dummy src_configure, and a call to econf || die 
>>"" for those packages not fixed to use that will return a bunch of erroneous 
>>packages not compiling.
>>
>>    
>>
>
>you could simply make the default:
>
>src_configure() {
>	[ -f ./configure ] && econf || die
>}
>
>- --
>
>smithj
>
>Gentoo Developer
>[ desktop stuff && netmon && documentation ]
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCzHcJl5AvwDPiUowRAqeFAJwIxve3a/X5BnlSBOxfv/Ac2lMAaACg30Pg
>62/3CVfdiHVSppJfEe73DsY=
>=lK9Q
>-----END PGP SIGNATURE-----
>  
>
By order of operations that won't work...I think you'll have to do if/then.

if [ -f ./configure ]
then
    econf || die
fi

But that's a possible solution for sure.  It would still introduce a lot 
of ebuild editing for those ebuilds doing special conf stuff though.

Joshua Baergen

P.S. I tried sending this earlier but my client barfed, so I apologize 
if it ends up double.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Roy Marples]

On Wed, 2005-07-06 at 20:14 -0400, Aron Griffis wrote:
> Sven Wegener wrote:	[Wed Jul 06 2005, 08:04:04PM EDT]
> > I'm writing this mail to bring you a thought we had over on freenode
> > in the #gentoo-portage channel. We would like to split up
> > src_compile. The new src_configure should just do the econf part and
> > src_compile should do the emake part. This represents the general
> > 3-step[1] installation in a much better way.
> 
> This would be great in that it would be possible to do:
> 
>     ebuild blah.ebuild configure
> 
> then change to the directory and work on it.  But the other side of
> the coin is that you're talking about a LOT of ebuild changes, right?


Why would it require ebuild changes?

src_compile() currently does config + compile

src_configure() does configure, src_compile() does compile. If the
ebuild does both and configs in both then - duh - shoot the ebuild
maintainer!

All that needs to be added to the ebuild proggy is

if [[ $( type -t src_configure ) == "function" ]]; then
  src_configure
elif [[ ${args} == "configure" ]]; then
   ewarn "No configure function in ebuild!"
fi
src_compile

ebuilds could be changed over time - unless I'm missing something basic
here ..

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Aron Griffis]

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

Joshua Baergen wrote:	[Wed Jul 06 2005, 08:43:34PM EDT]
> P.S. I tried sending this earlier but my client barfed, so I apologize 
> if it ends up double.

It would be less annoying if you wouldn't quote the entire previous
email in your replies.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] src_configure

[Aron Griffis]

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

Roy Marples wrote:	[Wed Jul 06 2005, 08:51:17PM EDT]
> ebuilds could be changed over time - unless I'm missing something basic
> here ..

Yes, you're missing the default functions.  Presently src_compile does
(effectively) "econf && emake" if the function isn't defined.  That
would be broken into two default functions now, but none of the
ebuilds have src_configure defined, so it would be broken for all of
them.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] src_configure

[Joshua Baergen]

Aron Griffis wrote:

>It would be less annoying if you wouldn't quote the entire previous
>email in your replies.
>  
>
Ehhe, my apologies...I've been spoiled by Gmail's hiding of previous emails.

Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Ian Leitch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sven Wegener wrote:
> Hi all!
> 
> I'm writing this mail to bring you a thought we had over on freenode in
> the #gentoo-portage channel. We would like to split up src_compile. The
> new src_configure should just do the econf part and src_compile should
> do the emake part. This represents the general 3-step[1] installation in
> a much better way.
> 
> Regards,
> Sven
> 
> [1] ./configure && make && make install

I made some patches[1] to do this years ago, I was told by the portage
devs at the time (can't remember who) that they should probably be
includes some time in the future. Maybe now is the time?

1:  http://dev.gentoo.org/~port001/Patches/configure-ebuild.sh.patch
    http://dev.gentoo.org/~port001/Patches/configure-portage-py.patch
    (NOTE: these probably don't apply anymore, seeing as they were made
    in december 2003).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCzIYXefZ4eWAXRGIRAuNNAKCQHoEqZ/vsMiOORxt27veqar4gkQCfdFLT
daFN7flKJXqo7eCEDfMYJGQ=
=fhld
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Thomas de Grenier de Latour]

On Thu, 7 Jul 2005 02:04:04 +0200
Sven Wegener <swegener@gentoo.org> wrote:

> We would like to split up src_compile. The new src_configure
> should just do the econf part and src_compile should do the
> emake part.

Just by curiosity, i've run a grep on the tree to count occurences
of "^[[:space:]]*econf" and "^[[:space:]]*\..*/configure" in
ebuilds. Here are the results (that's numbers of ebuilds, not
packages, grouped by the number of econf/configure they have):

 1: 5736
 2: 182
 3: 12
 4: 3
 5: 2
 7: 3

I would have thought this figures would be much worst, but that's
actually a few tenths of packages with 2 config calls, and only
~10 with 3+. 


Looking at some random ebuilds with 2+ econf/configure, it seems
that the most frequent pattern is something like that:
====================================================
src_compile() {
        econf  || die
	emake  || die
	if use foo ; then
		cd "${S}/foo-plugin"
	        econf || die
		emake || die
	fi
}
====================================================

Sure, spliting that will produce a bit of code duplication. It's
a bit less readable imho, but that's really just a cosmetic
issue: 
====================================================
src_configure() {
        econf  || die
	if use foo ; then
		cd "${S}/foo-plugin"
	        econf || die
	fi
}

src_compile() {
	emake  || die
	if use foo ; then
		cd "${S}/foo-plugin"
		emake || die
	fi
}
====================================================


I've also searched for some more problematic ebuilds, like some
which would configure & build the same source several times
(x11-libs/wxGTK maybe, also i'm not really sure) or some which
would first configure and build a libfoo/ subtree, and then
configure and build the main program (did not found any of that
kind, but i would not be surprised some exists).


If anyone want to have a look on my list to find some package
that may be problematic, it's here:
http://tdegreni.free.fr/gentoo/ebuilds_with_two_or_more_configure.list

(disclaimer: yup, keep in mind i've just done a quick grep on
the tree - this figures might not be completly meaningless, but
are for sure not accurate)

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Robin H. Johnson]

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

On Thu, Jul 07, 2005 at 04:32:32AM +0200, Thomas de Grenier de Latour wrote:
> Sure, spliting that will produce a bit of code duplication. It's
> a bit less readable imho, but that's really just a cosmetic
> issue: 
> ====================================================
> src_configure() {
>         econf  || die
> 	if use foo ; then
> 		cd "${S}/foo-plugin"
> 	        econf || die
> 	fi
> }
> 
> src_compile() {
> 	emake  || die
> 	if use foo ; then
> 		cd "${S}/foo-plugin"
> 		emake || die
> 	fi
> }
> ====================================================


> 
> 
> I've also searched for some more problematic ebuilds, like some
> which would configure & build the same source several times
> (x11-libs/wxGTK maybe, also i'm not really sure) or some which
> would first configure and build a libfoo/ subtree, and then
> configure and build the main program (did not found any of that
> kind, but i would not be surprised some exists).
I know know stuff that NEEDS this:
cd $S
econf && emake || die
cd $S/plugin/$foo
econf && emake || die

and the stuff in $bar/plugin/$foo REQUIRES that $S be built first.

But as a possible fix for this, we could break out the plugin to a new
package.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] src_configure

[Kumba]

Diego 'Flameeyes' Pettenò wrote:
> 
> That will be very very interesting but... but not everything uses ./configure, 
> so we should add a bunch of dummy src_configure, and a call to econf || die 
> "" for those packages not fixed to use that will return a bunch of erroneous 
> packages not compiling.

I know some packages off the top of my head, like Perl and OpenSSL use their own 
odd variants of configure.  There are likely many others.

Kernel ebuilds probably need special treatment, as they don't really go through 
a configure and compile phase.


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Daniel Drake]

Jonathan Smith wrote:
> you could simply make the default:
> 
> src_configure() {
> 	[ -f ./configure ] && econf || die
> }


No need, this will do fine as a default:

src_configure() {
	econf || die
}

Since econf already checks for a configure script and does nothing if it can't
find one...

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[twofourtysix]

On 07/07/05, Daniel Drake <dsd@gentoo.org> wrote:
> src_configure() {
>         econf || die
> }
> 
> Since econf already checks for a configure script and does nothing if it can't
> find one...

Yours might do. The one I have in /usr/sbin/ebuild.sh from portage
2.0.51.22-r1 says this:

econf() {
»·······local LOCAL_EXTRA_ECONF="${EXTRA_ECONF}"

»·······if [ -z "${ECONF_SOURCE}" ]; then
»·······»·······ECONF_SOURCE="."
»·······fi
»·······if [ -x "${ECONF_SOURCE}/configure" ]; then
+----- 78 lines: if [ -e /usr/share/gnuconfig/ ]; then--------------------------
»·······else
»·······»·······die "no configure script found"
»·······fi
}

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: src_configure

[Duncan]

Sven Wegener posted <20050707000403.GG20687@lightning.stealer.net>,
excerpted below,  on Thu, 07 Jul 2005 02:04:04 +0200:

> We would like to split up src_compile. The new src_configure should just
> do the econf part and src_compile should do the emake part. This
> represents the general 3-step[1] installation in a much better way.
> 
> [1] ./configure && make && make install

HALLELUJAH and much rejoicing!  The current combined configure/make step
frustrated me from the first time I looked at it.  I couldn't figure out
(and still can't) why a step-by-step modularized system, ostensibly
designed to allow local customization and troubleshooting, would combine
those two into a single step.  However, being a lowly user, new to Gentoo
at the time, I figured there had to be some major reason for ignoring
something so obvious, and just lived with it, by doing ebuild unpack, then
manually running the configure and make steps separately if needed, before
finishing up with ebuild package and then emerge --packageonly.

If the change is going to be implemented, please do so using something
similar to the current tracking system, whereby if a step is done
manually, one can simply touch a .action file to tell portage about it,
and have it continue with the next step.  (This bit me with the current
compile and .compiled file step, because the compile step does more than
compile, creating some metadata files as well.  I ended up creating a
local portage patch that I faithfully apply to each update, that allows me
to run the compile step without doing the actual compile, just updating
the metadata, so that it gets packed into the binpkg correctly, even when
I did the actual compile manually.  A second local portage patch makes
ebuild skip the install step if the .installed file is there. 
Unfortunately, while ebuild creates the file, it doesn't skip that step
if it exists, as it does with .unpacked, .compiled, etc.)

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Ned Ludd]

On Thu, 2005-07-07 at 02:04 +0200, Sven Wegener wrote:
> Hi all!
> 
> I'm writing this mail to bring you a thought we had over on freenode in
> the #gentoo-portage channel. We would like to split up src_compile. The
> new src_configure should just do the econf part and src_compile should
> do the emake part. This represents the general 3-step[1] installation in
> a much better way.

I'm in favor of this. It will however make the size of the tree grow
significantly. It would be nice if we could find somewhere else to trim
some the fat.

-- 
Ned Ludd <solar@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Martin Schlemmer]

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

On Thu, 2005-07-07 at 02:04 +0200, Sven Wegener wrote:
> Hi all!
> 
> I'm writing this mail to bring you a thought we had over on freenode in
> the #gentoo-portage channel. We would like to split up src_compile. The
> new src_configure should just do the econf part and src_compile should
> do the emake part. This represents the general 3-step[1] installation in
> a much better way.
> 

Will make debugging compile failures much easier imho.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] src_configure

[Martin Schlemmer]

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

On Thu, 2005-07-07 at 08:08 +0100, Daniel Drake wrote:
> Jonathan Smith wrote:
> > you could simply make the default:
> > 
> > src_configure() {
> > 	[ -f ./configure ] && econf || die
> > }
> 
> 
> No need, this will do fine as a default:
> 
> src_configure() {
> 	econf || die
> }
> 
> Since econf already checks for a configure script and does nothing if it can't
> find one...
> 

Well, besides the point that somebody else made that it dies if no
configure is present, it dies anyhow if it fails, so no need for the ||
die even ...

-----
src_configure() {
	if [[ -x configure && ! -f .econfigured ]] ; then
		econf
		touch .econfigured
	fi
}
-----

And might possibley make econf look for .econfigured as well, which
might help non split ebuilds that uses econf at least ...


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] src_configure

[twofourtysix]

On 07/07/05, Sven Wegener <swegener@gentoo.org> wrote:
> I'm writing this mail to bring you a thought we had over on freenode in
> the #gentoo-portage channel. We would like to split up src_compile. The
> new src_configure should just do the econf part and src_compile should
> do the emake part. This represents the general 3-step[1] installation in
> a much better way.

Whilst you're at it... Why not split unpack up into, say, unpack and
prepare? Make src_unpack's default stay the same and use src_prepare
for patches and autotools things? This will avoid the pointless
duplication of the default src_unpack code that's currently used in
many ebuilds.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] src_configure

[Henrik Brix Andersen]

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

On Thu, 2005-07-07 at 15:25 +0100, twofourtysix wrote:
> Whilst you're at it... Why not split unpack up into, say, unpack and
> prepare? Make src_unpack's default stay the same and use src_prepare
> for patches and autotools things? This will avoid the pointless
> duplication of the default src_unpack code that's currently used in
> many ebuilds.

Not a bad idea, actually...

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] src_configure

[Paul de Vrieze]

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

On Thursday 07 July 2005 03:14, Aron Griffis wrote:
> Roy Marples wrote:	[Wed Jul 06 2005, 08:51:17PM EDT]
>
> > ebuilds could be changed over time - unless I'm missing something
> > basic here ..
>
> Yes, you're missing the default functions.  Presently src_compile does
> (effectively) "econf && emake" if the function isn't defined.  That
> would be broken into two default functions now, but none of the
> ebuilds have src_configure defined, so it would be broken for all of
> them.

Another issue is the fact that current portage versions will not work with 
ebuilds with the new format. The format code at least should be out for a 
while before changing the ebuilds over.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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