| 1 |
On Sat, Aug 11, 2001 at 01:45:28AM +0200, Karl Trygve Kalleberg wrote: |
| 2 |
> One of the decisions to make is whether we should expose the underlying |
| 3 |
> configuration mechanism for the package, say by having a process much like |
| 4 |
> Pete described, where the user does: |
| 5 |
> 1) ebuild unpack |
| 6 |
> 2) edits a pre-generated <package-install-prefix>/gentoo-configure script |
| 7 |
|
| 8 |
2b) doing the configure |
| 9 |
|
| 10 |
2c) allow the sysadmin to edit them config.h files, |
| 11 |
and only then: |
| 12 |
|
| 13 |
> 3) ebuild merge |
| 14 |
> |
| 15 |
> In step 3, the portage system will use the modified gentoo-configure |
| 16 |
> script to configure the package, before running make and install. |
| 17 |
|
| 18 |
My problem with the merge step is the combined configure, compile install |
| 19 |
phases :( |
| 20 |
|
| 21 |
|
| 22 |
> The other approach, which would make creating ebuilds considerably more |
| 23 |
> difficult, was to have each ebuild read a parameter list from command |
| 24 |
> line, then apply these to the underlying configuration mechanism for the |
| 25 |
> relevant package. |
| 26 |
|
| 27 |
Which could become extremely troublesome when needing to edit a config.h file |
| 28 |
(like flwm as an example :() |
| 29 |
|
| 30 |
> |
| 31 |
> This would mean that the user doing installation wouldn't have to know the |
| 32 |
> intricacies of the underlying package (not all packages use automake), but |
| 33 |
> would only specify a parameter to ebuild, e.g: |
| 34 |
> ebuild clanlib-0.5.0.ebuild --with-3d |
| 35 |
> |
| 36 |
> Then it was up to the ebuild code to map the "--with-3d" parameter to |
| 37 |
> whatever was appropriate in clanlib (such as "--with-opengl"). Normally, |
| 38 |
> there would be a direct mapping. |
| 39 |
> |
| 40 |
> However, this puts the burden on the ebuild developer to export many (if |
| 41 |
> not all) of the compile-time switches, and perhaps even write some kind of |
| 42 |
> consistency-checker for some of the parameters, if the underlying |
| 43 |
> configuration systems doesn't handle that (say, the user specified |
| 44 |
> --without-x --with-gtk). |
| 45 |
> |
| 46 |
> |
| 47 |
> The current philosophy of portage (and consequently ebuild) has been KISS. |
| 48 |
> The Gentoo developers have opted for the easiest route, |
| 49 |
> implementation-wise. |
| 50 |
|
| 51 |
Which do take away my reasons for needing to build |
| 52 |
from source :( |
| 53 |
|
| 54 |
> |
| 55 |
> |
| 56 |
> This is definitely a topic that is relevant to the "Improving |
| 57 |
> Portage"-project I've suggested elsewhere. |
| 58 |
|
| 59 |
:) |
| 60 |
-- |
| 61 |
------------------------ |
| 62 |
Hendrik Visage |
| 63 |
hvisage@×××××××××××.za |
Archives