On 7/1/07, Michael Homer <[EMAIL PROTECTED]> wrote: > On 7/2/07, mpb <[EMAIL PROTECTED]> wrote: > > Hi, > > > > There was talk back in May of adding USE-flag style functionality to > > Compile: > > > > http://www.wotfun.com/pipermail/gobolinux-devel/2007-April/002570.html > > http://www.wotfun.com/pipermail/gobolinux-devel/2007-May/002580.html > <snip> > > > > You might, for example, want to Compile against Optional-Installed > > dependencies, but at the same time to Skip Optional-Absent > > dependencies. > Everything above this point sounds fine to me. It would be nice to > have more general flags than just dependencies, I think, but I haven't > come up with an example of why yet. I just have a niggling feeling > that enabling "GTK" might do more than just compiling against GTK. > Maybe more on that later if I can think of it.
If you think about "enabling GNOME" then I believe it gets easier to conclude that it's more than just compiling against one or other library. You'd probably want it to change dependencies and configure (as in "settings files") things in different ways. > What about cases where one flag affects another? Dependencies could be > mutually-exclusive, in fairly complex ways, or one could require > another, or one could require a disjunction of others (to enable > feature X you need Sun-JRE OR Sun-JDK OR Blackdown-JRE OR ...). > > That brings something else to mind: Gentoo has "virtual" packages to > cover cases where there are multiple implementations of the same > thing: virtual/ghostscript, virtual/x11, virtual/jre, virtual/emacs, > and others. Ebuilds are said to "provide virtual/ghostscript". That > sort of solution would remove a lot of the complexity, but probably > not all of it, and it might make a bit of a mess of /Programs. > Although symlinks /Programs/JDK->/Programs/Sun-JDK might not be so > bad. I think the same. Probably something to be added as a next step afterwards though (in other words, a good idea but not essential to the core of things). > I like the different levels of necessity. I am a little wary of how > recommended/discouraged is going to be determined, but I doubt it > would really be a problem. I also like the control there is at > different levels of detail. I am very wary about how this would be determined (thinking about community/social/flamewar implications, rather than technical issues). I'd rather avoid this can of worms and stick to something that can be unequivocally determined, reducing the spectrum to "required", "optional" and (the eventually phased-out) "unlabeled". Even then, there is always the issue of app-specific flags and whether they will be enabled or disabled by default (where being enabled by default amounts to being "recommended" and disabled by default to being "discouraged", I understand.) So, yes, to some degree it is an unavoidable problem (unless you want to shy away and ask the user everything). But its an unsolvable problem in the global sense, as it's impossible to make _everyone_ happy with the chosen defaults, but then that's why they're just "defaults" and not hardcoded behavior. (All right, I'm just rambling, throwing ideas to the table. I haven't made up my mind on this issue.) > > 2) Dependency Flavors would not handle the case of Compiling only a > > specific Xorg video driver. I believe "USE-flags"/Flavors should be > > used for cross-recipe configuration, not intra-recipe configuration. > > I'm not opposed to intra-recipe configuration mechanisms, but I think > > intra-recipe configuration is a separate (and much simpler) problem, > > and should be solved separately and without cluttering up the global > > "USE-flag" namespace. > It is cross-recipe. The recipe "Xorg" depends on the recipe > "XF86-Video-I810". I think solving intra-recipe and cross-recipe issues with the same mechanism would be better. Being pragmatic, I don't think cluttering up the "USE-flag" namespace is that big of a deal. Two things should help: one is avoiding to fall into the trap of trying to map every available configure flag; another is to define some namespace rules such as "if a flag is used in only one program, it must be prefixed by the program name". > > 3) In the case of PHP and other highly configurable and ever changing > > Programs where users are likely to have exacting needs, I feel better > > served by a simple recipe that allows me to pass args thru to > > ./configure. Gentoo's complicated (and often-masked) php .ebuilds > > regularly frustrated me. As a result, back in the days when I used > > Gentoo I usually ended up compiling PHP by hand. With GoboRootless, I > > simply store store my PHP configure args in a Makefile that calls > > Compile, which is a much nicer solution. > I would still like to have the options be available where they exist > anyway, even if they aren't actual dependencies. In the case of PHP, > it bundles a lot of libraries that it uses internally, but the > extensions can still be enabled or disabled (for policy reasons, or > because you just don't want to waste time compiling thirty database > drivers). Those bundled libraries wouldn't be dependencies, but there > would often be flags for the same subject anyway used elsewhere. I'd > like them to be used where available. > > If we're passing configure args, I would definitely want them to be > saved and defaulted on subsequent compiles. Otherwise it's asking for > unexpected breakage. Yeah, that would be nice, and for --configure-options, even implementable today before having actual use-flags. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
