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" > > I agree on this point, for the same reasons. Anyway I think using the solution suggested by Jonatan can easily become cumbersome. It would be theoretically necessary to disable every single package which we don't want to be detected by the recipe, and parallel to this, adding a with_<useflag>. Hence I believe it'd be better to actually take care of this by using some different format, something like
with_useflags=( "gtk1?--enable-gtk:--disable-gtk" "foo?--with-foo:--without-foo" ... ) which I think could be parsed in a convenient way. Every element means just what the C-like syntax says: "if we want gtk to be enabled, add --enable-gtk, --disable-gtk otherwise". Then for every useflag defined in the Dependencies file with a match in the user's preferences, we would only have to find it in the array and using the correct option thereafter. On the other hand, it would add some complexity to scripts, mainly due to the need to implement the parsing for the new array. What do you think? Maybe these are just the ravings of a lunatic, dunno :D _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
