[gentoo-dev] Customize a ebuild before compiling

[gentoo-dev] Customize a ebuild before compiling

[Hendrik Visage]

Hi there,

 One of my personal main "gripes" about the portage/ports/.srpm etc.
setups, are that I can't "tune" the installation in a managed fashion,

 An example is flwm (Nothing against tadpol, thanx for the -r1 :) 
that have some interesting configuration changes that can only be made in 
the config.h file before compilation.

Now my wishlist for ebuilds etc.
 I'd like to have a interactive setup or step by step changes,
ie.
 issue the standard installation (Let's see if it install by default)
 Then I'd like to ask it to extract the package, but to let me add some extra
./configure options (Enable this or disable that), eg. I'd like to have a text
console only xemacs, or I'd like to have xaw instead of lucid menus etc. etc.
 Then I'd like it to do the configure, and after that I'd like the possibility
to vi some config.c for some changes in the system in the way *I* want it.
 Then let it do the compile & install.

Or am I missing a documentation page??

-- 
------------------------
Hendrik Visage
hvisage@envisage.co.za

Re: [gentoo-dev] Customize a ebuild before compiling

[Pete Gavin]

Hi Hendrik,

This is basically the premise behind USE variables, but its
non-interactive and provides consistency throughout the system. So,
for example, xemacs will only provide X11 support if the "X" USE
variable is set, or Xaw will be used if "xaw" is in USE. This doesn't
really allow extremely fine-tuned customizations, but occaisionally,
if I really need to, I'll do ebuild unpack, then configure stuff the
way I want it, then do ebuild compile merge. This is definitely
cheating though :)

Pete
<alkaline@gentoo.org>

On Thu, Aug 09, 2001 at 09:53:02PM +0200, Hendrik Visage wrote:
> Hi there,
> 
>  One of my personal main "gripes" about the portage/ports/.srpm etc.
> setups, are that I can't "tune" the installation in a managed fashion,
> 
>  An example is flwm (Nothing against tadpol, thanx for the -r1 :) 
> that have some interesting configuration changes that can only be made in 
> the config.h file before compilation.
> 
> Now my wishlist for ebuilds etc.
>  I'd like to have a interactive setup or step by step changes,
> ie.
>  issue the standard installation (Let's see if it install by default)
>  Then I'd like to ask it to extract the package, but to let me add some extra
> ./configure options (Enable this or disable that), eg. I'd like to have a text
> console only xemacs, or I'd like to have xaw instead of lucid menus etc. etc.
>  Then I'd like it to do the configure, and after that I'd like the possibility
> to vi some config.c for some changes in the system in the way *I* want it.
>  Then let it do the compile & install.
> 
> Or am I missing a documentation page??
> 
> -- 
> ------------------------
> Hendrik Visage
> hvisage@envisage.co.za
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
> 

Re: [gentoo-dev] Customize a ebuild before compiling

[Karl Trygve Kalleberg]

On Thu, Aug 09, 2001 at 09:53:02PM +0200, Hendrik Visage wrote:
> Hi there,
> 
>  One of my personal main "gripes" about the portage/ports/.srpm etc.
> setups, are that I can't "tune" the installation in a managed fashion,
> 
>  An example is flwm (Nothing against tadpol, thanx for the -r1 :) 
> that have some interesting configuration changes that can only be made in 
> the config.h file before compilation.
> 
> Now my wishlist for ebuilds etc.
>  I'd like to have a interactive setup or step by step changes,
> ie.
>  issue the standard installation (Let's see if it install by default)
>  Then I'd like to ask it to extract the package, but to let me add some extra
> ./configure options (Enable this or disable that), eg. I'd like to have a text
> console only xemacs, or I'd like to have xaw instead of lucid menus etc. etc.
>  Then I'd like it to do the configure, and after that I'd like the possibility
> to vi some config.c for some changes in the system in the way *I* want it.
>  Then let it do the compile & install.

One of the decisions to make is whether we should expose the underlying
configuration mechanism for the package, say by having a process much like
Pete described, where the user does:
1) ebuild unpack 
2) edits a pre-generated <package-install-prefix>/gentoo-configure script
3) ebuild merge

In step 3, the portage system will use the modified gentoo-configure
script to configure the package, before running make and install.

This can be handled by portage, more or less by dumping
src_compile() to the gentoo-configure file.


The other approach, which would make creating ebuilds considerably more
difficult, was to have each ebuild read a parameter list from command
line, then apply these to the underlying configuration mechanism for the
relevant package.

This would mean that the user doing installation wouldn't have to know the
intricacies of the underlying package (not all packages use automake), but
would only specify a parameter to ebuild, e.g:
ebuild clanlib-0.5.0.ebuild --with-3d

Then it was up to the ebuild code to map the "--with-3d" parameter to
whatever was appropriate in clanlib (such as "--with-opengl"). Normally,
there would be a direct mapping.

However, this puts the burden on the ebuild developer to export many (if
not all) of the compile-time switches, and perhaps even write some kind of
consistency-checker for some of the parameters, if the underlying
configuration systems doesn't handle that (say, the user specified
--without-x --with-gtk).


The current philosophy of portage (and consequently ebuild) has been KISS.
The Gentoo developers have opted for the easiest route,
implementation-wise.

> Or am I missing a documentation page??

No, we do not have direct support for this.



This is definitely a topic that is relevant to the "Improving
Portage"-project I've suggested elsewhere.

Regards,

Karl T

Re: [gentoo-dev] Customize a ebuild before compiling

[Hendrik Visage]

On Sat, Aug 11, 2001 at 01:45:28AM +0200, Karl Trygve Kalleberg wrote:
> One of the decisions to make is whether we should expose the underlying
> configuration mechanism for the package, say by having a process much like
> Pete described, where the user does:
> 1) ebuild unpack 
> 2) edits a pre-generated <package-install-prefix>/gentoo-configure script

2b) doing the configure

2c) allow the sysadmin to edit them config.h files,
and only then:

> 3) ebuild merge
> 
> In step 3, the portage system will use the modified gentoo-configure
> script to configure the package, before running make and install.

My problem with the merge step is the combined configure, compile install
phases :(


> The other approach, which would make creating ebuilds considerably more
> difficult, was to have each ebuild read a parameter list from command
> line, then apply these to the underlying configuration mechanism for the
> relevant package.

Which could become extremely troublesome when needing to edit a config.h file
 (like flwm as an example :()

> 
> This would mean that the user doing installation wouldn't have to know the
> intricacies of the underlying package (not all packages use automake), but
> would only specify a parameter to ebuild, e.g:
> ebuild clanlib-0.5.0.ebuild --with-3d
> 
> Then it was up to the ebuild code to map the "--with-3d" parameter to
> whatever was appropriate in clanlib (such as "--with-opengl"). Normally,
> there would be a direct mapping.
> 
> However, this puts the burden on the ebuild developer to export many (if
> not all) of the compile-time switches, and perhaps even write some kind of
> consistency-checker for some of the parameters, if the underlying
> configuration systems doesn't handle that (say, the user specified
> --without-x --with-gtk).
> 
> 
> The current philosophy of portage (and consequently ebuild) has been KISS.
> The Gentoo developers have opted for the easiest route,
> implementation-wise.

Which do take away my reasons  for needing to build
from source :(

> 
> 
> This is definitely a topic that is relevant to the "Improving
> Portage"-project I've suggested elsewhere.

:)
-- 
------------------------
Hendrik Visage
hvisage@envisage.co.za

Re: [gentoo-dev] Customize a ebuild before compiling

[tadpol]

On Sat, Aug 11, 2001 at 06:52:22PM +0200, Hendrik Visage wrote:
> On Sat, Aug 11, 2001 at 01:45:28AM +0200, Karl Trygve Kalleberg wrote:
> > One of the decisions to make is whether we should expose the underlying
> > configuration mechanism for the package, say by having a process much like
[snip]
> > The current philosophy of portage (and consequently ebuild) has been KISS.
> > The Gentoo developers have opted for the easiest route,
> > implementation-wise.
> 
> Which do take away my reasons  for needing to build
> from source :(


There will always be packages that are too `weird' to be handled by any
system we come up with.

At a certain point, the extra complexity needed for this kind of stuff is
not worth the time.

/usr/local/(bin|sbin|share|doc|*) exists for a reason.  If you have
packages that require that level of customization, it is probably beyond
what a package system should do.


This all of course is my own personal opinion,
-- 
Michael Tilstra                       tadpol@tadpol.org
Software is like sex; it's better when it's free. - Linus Torvalds

Re: [gentoo-dev] Customize a ebuild before compiling

[Hendrik Visage]

On Sat, Aug 11, 2001 at 01:28:22PM -0500, tadpol@tadpol.org wrote:
> On Sat, Aug 11, 2001 at 06:52:22PM +0200, Hendrik Visage wrote:
> > On Sat, Aug 11, 2001 at 01:45:28AM +0200, Karl Trygve Kalleberg wrote:
> > > One of the decisions to make is whether we should expose the underlying
> > > configuration mechanism for the package, say by having a process much like
> [snip]
> > > The current philosophy of portage (and consequently ebuild) has been KISS.
> > > The Gentoo developers have opted for the easiest route,
> > > implementation-wise.
> > 
> > Which do take away my reasons  for needing to build
> > from source :(
> 
> 
> There will always be packages that are too `weird' to be handled by any
> system we come up with.
> 
> At a certain point, the extra complexity needed for this kind of stuff is
> not worth the time.
> 
> /usr/local/(bin|sbin|share|doc|*) exists for a reason.  If you have
> packages that require that level of customization, it is probably beyond
> what a package system should do.

Which breaks the idea of a packaging system :(

Even worse, I'd like to build a special version of gtk (thumb sucking),
and wish everything from then on to make use of this version.

If I'm going to install in /usr/local, then the portage system isn't
going to pick it up (easily I guess) that I've installed version x.y.z_patched
and that it don't need to build x.y.z and to configure/compile against /usr/local
instead of the "old" /usr version...

How can we still link in with the dependency & packaging system, 
without breaking portage etc. and not making use of ebuild???

> This all of course is my own personal opinion,

Mine too ;)

-- 
------------------------
Hendrik Visage
hvisage@envisage.co.za

Re: [gentoo-dev] Customize a ebuild before compiling

[Nathaniel Grady]

I tend to have a lot of "odd" prefrences (or quirks) in relation to compile-time options as well. I think just mentioning in the emerge docs the steps to get ebuild to extract / patch / pause for you to manually configure / compile / install would be enouhg to make me happy, and probably anyone else who knows what they are doing well enouhg to want to do such a thing... imho anyhow :)

--Nathaniel Grady

Re: [gentoo-dev] Customize a ebuild before compiling

[tadpol]

On Sat, Aug 11, 2001 at 09:09:26PM +0200, Hendrik Visage wrote:
> On Sat, Aug 11, 2001 at 01:28:22PM -0500, tadpol@tadpol.org wrote:
> > /usr/local/(bin|sbin|share|doc|*) exists for a reason.  If you have
> > packages that require that level of customization, it is probably beyond
> > what a package system should do.
> 
> Which breaks the idea of a packaging system :(

No it doesn't.  look at rpm, deb, slackware and bunch others.  That level
of configurablity doesn't exist.  And the package systems still work.

Portage is closer to a build system than it is a package system.  A build
system could do what you suggest below, a package system couldn't.

> Even worse, I'd like to build a special version of gtk (thumb sucking),
> and wish everything from then on to make use of this version.
> 
> If I'm going to install in /usr/local, then the portage system isn't
> going to pick it up (easily I guess) that I've installed version
> x.y.z_patched and that it don't need to build x.y.z and to
> configure/compile against /usr/local instead of the "old" /usr version...
> 
> How can we still link in with the dependency & packaging system, 
> without breaking portage etc. and not making use of ebuild???

This would be a wonderful case for the local ebuild thing someone suggested
earlier.  Basically something that lets you define ebuilds that are local
to your setup.


I just think that kind of configuration system is overkill for 90% of the
ebuilds.  And I don't see the extra complexity worth the price of a few
packages.

> > This all of course is my own personal opinion,
> Mine too ;)
oy, so many opinions to choose from...   ^_^

-- 
Michael Tilstra                       tadpol@tadpol.org
I'll do all these things, because I'm an idiot.

Re: [gentoo-dev] Customize a ebuild before compiling

[Mikael Hallendal]

Hi!

> Portage is closer to a build system than it is a package system.  A build
> system could do what you suggest below, a package system couldn't.

One way to solve this kind of issues could either be:
1a) add a src_compile () stage in portage.
1b) make a stage (ie, compile, install, qmerge) not excecute the stages
before them. That way you could do: ebuild unpack (), configure the
source by hand, excecute 'ebuild foo-0.1.ebuild compile install
qmerge'.

The other way (this can of course be valid even if the first is used.
And thats the local portage tree I suggested (which Drobbins seems to
want to add). To those who did not follow that discussion, here is
basically what it's about.

You add a variable in /etc/make.{globals,conf} named LOCAL_PORTDIR. When
emerging a package needing some package, you first look in LOCAL_PORTDIR
for the package, if it's not there, look in PORTDIR.

Me as a developer would really like this approach since I often build
lots of gnome stuff from CVS. This way I can have my cvs-ebuilds in
LOCAL_PORTDIR without corrupting my regular PORTDIR. Here you can also
have the kind of ebuilds where you want to have other compile-flags or
sed-script that changes stuff in config.h or whatever.

The strategy of making the ebuilds export configure-flags is really bad
(Imho). This would create unmaintainable ebuilds, make it much harder
for new ebuild developers, etc...

Regards,
Mikael Hallendal

Re: [gentoo-dev] Customize a ebuild before compiling

[Karl Trygve Kalleberg]

On Sun, Aug 12, 2001 at 12:04:26PM +0200, Mikael Hallendal wrote:

> You add a variable in /etc/make.{globals,conf} named LOCAL_PORTDIR. When
> emerging a package needing some package, you first look in LOCAL_PORTDIR
> for the package, if it's not there, look in PORTDIR.

It is very unnatural to stop there. Some developers might very well want to
'subscribe' to several PORTDIRs. This is common with Debian, where wine, 
mozilla, galeon, cclan, etc have their own cutting-edge trees which some 
developers want to stay in sync with.

An concrete example for Gentoo: I'm working on the Linux for Dreamcast port,
and we need very specialised tools and libraries that do not fit into the 
regular Gentoo tree (how many of the Gentoo users have a Dreamcast, and how
many of those who have are interested in building stuff for it ?).

In this case, we'd like to have our own portage tree specific to the Dreamcast
development that people could rsync against. 

(We'd also like to use Portage to generate platform-agnostic RPM/DEB
files, but that's another matter ;)

Regards,

Karl T

Re: [gentoo-dev] Customize a ebuild before compiling

[Damon M. Conway]

 Hendrik Visage wrote:
>Even worse, I'd like to build a special version of gtk (thumb sucking),
>and wish everything from then on to make use of this version.

Do what I do.  Munge the ebuild to use what you want it to use.  It's just
a bash script, and (in general) executes configure just like any user
would.  Add your options, and merge it.

Right now, I think there are more important things to focus on than trying
to handle special cases.  Let's hit the 90% mark, and worry about the last
10% when we have a working stable system.

throwing pennies,
Damon/kabau

--
"UNIX was not designed to stop you from doing stupid things, because that
 would also stop you from doing clever things."  --Doug Gwyn