On Sat, Apr 12, 2008 at 10:55 PM, Jonatan Liljedahl <[EMAIL PROTECTED]> wrote: > Jonatan Liljedahl wrote: > > Michael Homer wrote: > > ... > >> In most cases, dependencies are autodetected by configure correctly > >> and no change to the Recipe file will be necessary. In that case, the > >> with_<flag> variables should *not* be used only to convey redundant > >> information, and the flag should just be listed appropriately in > >> Dependencies. Note that this means that unlike Gentoo's, our flags are > >> not exclusive: their support may be compiled in even if the flag is > >> disabled, if the dependency is installed and autodetected correctly. > >> Compilations using ChrootCompile will not experience this effect, as > >> the dependency will be left out of the chroot environment. > > > > I don't like this, I might very well have some library installed just > > because a few programs *need* it to compile, while I still want to avoid > > using it in all apps that can manage without it. > > > > It may be libraries that I don't like, or that introduces > > incompatibilities with other functions in the app (like karts or esd), > > or that are deprecated and which I'm trying to get rid of (like GTK 1.x). > > > > This is easily fixed in the recipe: > > > > configure_options=( "--disable-gtk1" ) > > with_gtk1="--enable-gtk1" > > Another way would be to specify explicitly how to disable something: > > without_gtk1="--disable-gtk1" > with_gtk1="--enable-gtk1" We decided specifically against this, because it will blow up the recipes to ugly and unmaintainable lengths and we don't want to encourage it. The goal is always "to make Compile as smart as it can and the recipes as small as possible"[1]. In any case, note that ChrootCompile is slated to become the default behaviour at some point, in which case it will behave how you want via autodetection. If it's really, really necessary to do this in a recipe, it's possible in the way you suggested in the last post.
The other factor in that decision was reducing annoyance at having to recompile something because you'd missed out a flag after installing the dependency. > It may also sometimes be needed to have a not_using_<flag>() function, > if the default is to include the behaviour of the flag and that exlusion > can not be overridden by a using_flag() function like with overriding > configure options... Maybe. If it turns out to be necessary, we can add it later. It won't be for this use case, though, but I can see possibilities when it might be needed. [1] http://developers.slashdot.org/article.pl?sid=04/06/05/1949213 -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
