2008/9/22 Hisham <[EMAIL PROTECTED]>: > On Mon, Sep 22, 2008 at 3:37 AM, Michael Homer >>> My distant, high-level perception of the issue: if I don't have >>> "tcltk" listed in my "gui" flags, or if I have "-tcltk" explicitly >>> listed in my flags configuration, then I _really_ don't want to see >>> any optional Tcl/Tk GUIs being built from any recipe I compile. >> How about just one of them, the one where you take it out of the generic >> flag. >> All other ways lie madness and spooky action at a distance. "There's more >> than one way to do it" isn't a good philosophy for configuration files, and >> one of the ways is a necessity here. >> >> -foo removes foo from the set of enabled flags at that point. That's all. If >> foo isn't in the set, that's a no-op. +foo adds foo to the set. If foo is >> already there, that's a no-op. There's no magic behaviour. Adding one flag >> will never remove others, and removing one will never cause weird behaviour >> later on. If a generic flag is turned on at the end of that, it takes the set >> and does its thing in the way you asked in your GenericFlags.conf. > > So, if a generic flag adds foo at some point (dist or system) and then > I do -foo at the very last step (environment var), I'm still getting > rid of foo, right? > > Case in point: > > Scenario 1: if dist flags sets "gui: qt gtk tcltk" and system flags > sets "+gui" and I run "USE=-tcltk" on a recipe that has an optional > Tcl/Tk GUI, do I get a Tcl/Tk GUI built? > > Scenario 2: if dist flags sets "-tcltk" and system flags sets "gui: qt > gtk tcltk" and I run "USE=+gui" on a recipe that has an optional > Tcl/Tk GUI, do I get the optional Tcl/Tk GUI? > Clarification: Generic flags are defined in Settings/GenericFlags.conf. Setting flags you do in Data/DistUseFlags.conf, Settings/UseFlags.conf and USE environmental variable.
Flags are parsed and enabled in this order: DistUseFlags.conf, Settings/UseFlags.conf, USE environmental variable, flags selected by generic flags > My main concern is that the answer for scenario 1 is "no". I don't > mind if the answer for scenario 2 is "yes" or "no", as long as the > semantics are clearly defined. (Is the behavior of scenario 2 the > point of disagreement between Michael and Jonas?) > Scenario 1: Today: yes. With my implementation: no. Scenario 2: Today: probably(!) - if best gui available. With my implementation: Same as today The disagreement is not in scenario 2, but in scenario 1. I want "-tcltk" to affect what the generic flags enable. Today generic flags are parsed last and if no specific flag in a group is set in an earlier stage the generic flag will enable best available. I want that setting "-tcltk" in an earlier stage will not enable tcltk, even when it is the best available or only (if optional) gui. Why you get "probably" for scenario 2 with my implementation even though -tcltk is defined is that you reset the "gui" behaviour by setting +gui in a later stage. > In any case, the trouble I'm having to understand the example Jonas > gave (apart from his inconsistent use of flag names ;) ) is probably > an indication that the whole thing is already pretty (too?) > complicated. > I'm hoping, partly by resolving these issues, that we can make a clear definition of how use flags works. Right now it might look a bit unclear but that is because two ideas are put up side by side. The behaviour is clear defined already, but I disagree with the current behaviour. :) >>> OTOH, >>> when I build aMSN, which has a Tcl/Tk GUI, I want that built on the >>> basis that Tcl/Tk is a mandatory dependency for it, and therefore it >>> should not be conditioned to a flag in the recipe. >> If a recipe flags a mandatory dependency, that recipe is broken. That >> shouldn't ever be a problem so long as we're paying attention in what goes >> into the store. > > Good, looks like everyone agrees on this second part :) > I would even take it as far as recommended dependencies, that enables behaviour the user really expect, should not be flagged. -- /Jonas _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
