On Sat, 29 Dec 2007 22:47:50 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > > Have a look at the labels bug (201499). > > Similar idea, but I don't like the labels that much, > > having separate vars can make backward compatibility easy
You can't sensibly have backwards compatibility across new deps if all the requested options are implemented anyway -- there's no exact mapping between the current three vars and all the new ones. New deps has to be an EAPI change, and it has to be an ebuild change. And the other problem -- we'd be talking hundreds of variables. Multiply number of dep types (build, run, install, compile against, post, probably more) by number of requirement levels (required, suggested, recommended) by number of ABI combinations by number of system combinations by whatever else ends up being useful. > >> - explicit ctarget support in the package manager emerge > >> --cross=target something. > > > > Would need support from every ebuild, which in turn would need > > support from every upstream. > > every autostuff ebuild should and that's a start. Except that autotools doesn't have any sane way of handling chost / cbuild / ctarget for non-trivial packages. If you want to do something simple like generate a file using a program you make at compile time, you're forced to resort to nicking insane hackery from the gcc build system -- or you can do what most people do and just break non-native compiles. Using autotools does not mean supporting chost / cbuild / ctarget properly... > you can restrict the tree to a specific branch supporting this feature > and extend it little by little. Tree branching will very quickly become unmanageable. Users will be forced to choose a branch, but useful features will be spread across different branches. -- Ciaran McCreesh
signature.asc
Description: PGP signature
