Sorry for messing up the quotes earlier, hopefully this will come out better.
However I don't know how it will affect long rows, so it's kind of an
experiment.
On Sun, 06 May 2007 00:39:54 +0200, <[EMAIL PROTECTED]> wrote:
> On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
>> On Sat, 05 May 2007 01:40:48 +0200, Michael Homer
>> > On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
>> >> On Fri, 04 May 2007 21:42:14 +0200, Hisham Muhammad
>> >> > On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
>> >> >> On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >> >> > On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
>> >> >> > > One component of my original idea was to have installed programs
>> >> >> > > automatically become enabled flags, which would have that effect.
>> >> >> >
>> >> >> > That's basically what I had in mind too.
>> >> >> >
>> >> I can see the use of this, but I don't agree. This should not be flags,
>> >> but automatic settings. If an application optionally depend on say gtk+ to
>> >> be built with gui and I choose not to install it when Compile ask me, this
>> >> setting should be passed to configure.
>> >>
>> >> Flags should be more generic and be of value to the user. For example a
>> >> '--with-gtk' flag would automatically install gtk+ for me (if I didn't
>> >> have it installed) in the example above. The gui setting for the
>> >> application I want to install has little to do with flags. It's just a
>> >> "symptom".
>
> I didn't understand what you said, I think there was a mix up here.
> What we meant by "flags" there were "use flags", as in "global
> variables set somewhere that enable a 'flag' to be used by
> Compile/dependencies", but not command-line flags as in '--with-gtk'.
>
Maybe I used a bad example when refering to flags, but the former definition of
flags is the same as I have. Even if I sometimes refer to use flags as
'--with-foo' I basically mean the same thing as you do.
>> >> I don't think the problem lies in if I want to build with gui or not, but
>> >> to me the issue is if I want to have gtk+ installed or not, hence the flag
>> >> should be about that, not the configure options.
>> > The flag would be "GTK", not "GUI", since one program could have
>> > several different GUI options. So it would be basically like you
>> > describe, I imagine.
>> >
>> Ok, but my main point was that controlling wether an application is built
>> with or without GTK+ interface isn't what use flags should be used for.
>
> I disagree. I'd like to, for example, be able to build Vim with or
> without the GTK+ GUI using the same recipe; same for MPlayer...
> without having, for each app, to get the app's configure script, check
> its --help and figure out what flags I should pass to
> --configure-options (not to mention not all uses of USE flags would
> involve ./configure options only; some need to change makefile
> targets, pass extra variables, etc.)
>
Ok, what I meant with per-application-basis I meant that I don't see the point
(well I do see a point, but I think it's too complicated) to have specific use
flags for each appliction. Then one would have to look up the use flags in the
recipe, instead of, like in your example, check configure's --help output, so
it will have the same level of complexity to me. Then I don't see the gain -
instead of looking up configure options I have to look up use flags.
You should still be able to change how an application is compiled by changing
the use flags before compilation, like our (favourite) example set without_gtk
to have mplayer build without gtk interface. {with,without}_gtk is too me a
"good" use flag - it can be applied to every application that use that library.
What I'm afraid of is that the use flags will be too application specific, like
"without_gmplayer" and "without_gaumix" to disable those interfaces in those
applications, intead of just "without_gtk".
>> >> Flags shouldn't be about configure options, therefore this isn't needed.
>> >> In the example above, is it really important to be able to specify if I
>> >> want to build with gui or not, if I already have gtk+ installed? And if we
>> >> design this right, we don't have to use these micro controlling
>> >> mechanisms.
>> > I think it is, yes. Especially when there are multiple options.
>>
>> Are you trying to say that choosing wether GTK+ interface is built for an
>> application, even if GTK+ is already installed, is important? Why?
>
> Yes, because I don't want gmplayer or gaumix in my system, but I have
> GTK+ for using Gimp.
>
You have to explain this view to me as I can't really see the problem with
having gmplayer, as well as the "normal" mplayer, present on a system at the
same time. Does something break if gmplayer is installed as well, or is it just
you that don't want it?
> We should build the GTK+ interface if the "gtk" use-flag is set in the
> system or passed by the user to Compile as a one-off setting from the
> command-line. This will add GTK+ as a dependency to the app (which
> will cause it to install GTK+ if absent). Occasionally (for mplayer or
> aumix) I may want to disable my global "gtk" setting from the
> command-line.
>
My idea is to do it the other way around, build the GTK+ interface if GTK+ is
available and 'without_gtk' is unset, that is if we can build the interface and
the user hasn't explicity turned it off we will build it.
>> >> >> > > It might also be necessary to allow per-program flags (as in,
>> >> >> > > "enable
>> >> >> > > the GTK+ interface to Foo, but don't build the Qt one, even
>> >> >> > > thought I
>> >> >> > > have both installed"). I don't know how would be best to go about
>> >> >> >
>> >> I can't see why this is useful.
>> > Compile time? Mutual exclusivity? It's not necessarily the case that
>> > something wouldn't -work- because it you couldn't do that, but there
>> > is utility in it.
>> This shouldn't be set by application basis like this. If there are mutual
>> exclusive options like this we should select a working default. If the
>> user wants to change this we could provide options for that, but that's
>> not necessary. Something like below should be enough and if the user wants
>> to configure (mess with) the options more, he/she should use
>> '--configure-options'.
>>
>> with_gtk=(
>> --enable-gtk-ui
>> --disable-qt-ui
>> )
>> with_qt=(
>> --disable-gtk-ui
>> --enable-qt-ui
>> )
>
> I didn't get what this means. But in any case I don't think we should
> direct users to use --configure-options as a "poor man's use-flags".
> As I mentioned above, --configure-options is not general enough.
>
What I meant is that we can't create use flags for every possible permutation
of all the configure options and all other variables we can set to make the
recipe behave a special way. Instead we have to let the user have another way
of configuring the application the way he/she wants.
In my example I tried to show how an application could be configured with
"global" use flags intead of application specific. I don't like the idea of
having specific flags for one application, the flags should be more general.
However I can see the use of derived flags like 'foo_without_gtk' to make the
'without_gtk' flag set when compiling application 'foo'.
>> We can't design a solution that works for every case. We should design a
>> solution that is usable, not one that has a use for every problem possible.
>
> We should design a "simple things simple, complex things possible" solution.
>
Yes, but the important thing is to keep simple things simple when one expands
the possible uses.
>> Yes, but I'm still trying to separate the automatic feature-thingy and
>> "use" flags. The automatic processes can be controlled _indirect_ by "use"
>> flags, but they should not be controlled directly.
>
> I don't understand why/what you see as two different things here.
>
The things I see as separate is use flags and application control. I guess I'm
still stuck on the gui example, where I believe the gui should be built if the
library is present (and the user hasn't explicity turned building gui off)
therefore being automitic use flags - application control. My take on use flags
is more on how dependencies will be handled and indirectly how an application
should be built. Maybe I'm missing something but I fail to see what we would
benefit from application specific use flags. One still has to go through all
use flags (instead of configure options) to be able to build an application the
way a user wants.
>> I don't like the thought of having recipes depend/use
>> alot of functions from Scripts and Compile. They [recipes] should be as
>> static as
>> possible and self contained.
>
> Me too, but one can argue that these functions only modify variables
> and don't perform any actions on the filesystem. So, the "static"
> nature of recipes that loading them only loads a set of variables (and
> hook functions) is retained. (In "loading" there I include running the
> {using,not_using}_* functions, which should be looked at differently
> than the {pre,post}_* hook functions, which _are_ imperative). If
> needed, RecipeLint can do the checks to ensure that the using_*
> functions are declarative (ie, only set variables and call allowed
> functions).
>
>> I agree that functions would (could?) be more powerful, but is that really
>> needed? Isn't static arrays enough? KISS.
>
> Static arrays aren't enough, because there may be other variables to
> be changed other than configure_options. And expanding the arrays
> scheme to handle every variable possible makes things less simple/tidy
> than using functions.
>
Ok, you've convinced me that (dumbed down) functions are needed. :)
>> >> >> It's not really plausible to have functions
>> >> >> for every combination, and you can't nest them. I suppose the smart
>> >> >> functions cover the common case even there, so it might not be worth
>> >> >> worrying about. I am thinking of complex programs here, like PHP (107
>> >> >> flags in portage, many of which are codependent).
>> >> >
>> >> > One fear I always had about use flags is that they could make recipes
>> >> > more complicated and less maintainable... I'd rather add flags only
>> >> > where people need them, and not map all ./configure options of an app
>> >> > in a recipe "just because". This is more of a policy/guideline than a
>> >> > technical issue, but I believe that even with use flags we should
>> >> > strive to keep recipes as small as we can. ("Somebody might want to
>> >> > enable xyz" is not a good enough argument to me.)
>> >> >
>> > I agree. A lot of those flags are redundant (mysql vs mysqli). It's
>> > still plausible that something could get dozens of them legitimately,
>> > although it's not going to be too common. PHP is unusually
>> > complicated.
>> >> As stated above, flags should be system wide settings. For enabling "just
>> >> that feature" we have '--configure-options'.
>
> But we're not happy with that. :)
>
Why not? As I said, one could still save the options passed, so that
recompilations use the same options. What is the difference on having a use
flag for each configure option and specifying a configure option? We can't map
a use flag for every configure option.
>> >> >> I guess that this would also make all enabled dependencies mandatory,
>> >> >> which was another issue that came up a while back.
>> >> >
>> >> > Looking back, having dependencies accepted/rejected by the user was a
>> >> > primitive way of having something like use flags. I'd still like to
>> >> > have a power-user-friendly "force" mode, but the default behavior
>> >> > could switch to not compile/install if dependencies can't be matched.
>> >> >
This is my idea of use flags. More like choosing what dependencies a user wants
to install than how an application should be compiled.
>> > So from what's been said so far, I think it should be possible to
>> > build a system that is simple for the large majority of cases without
>> > cluttering things too much, or losing functionality from binary
>> > packages and such. I like the system Hisham put forward for it.
>>
>> To me this still looks a bit complicated and overworked. Too many
>> (unrelated) things go into the use of "use" flags. Ok, so Gentoo has a use
>> flag for almost every configure option in every application (haven't used
>> gentoo that much, uninstalled it as quickly as I could, just after I built
>> it)? To me this is not the right way to go.
>
> I agree with this part (as I stated above in this thread), but I
> disagree that --configure-options is the solution.
>
If we don't use --configure-options to solve this, what solution do you have to
this problem?
--
/Jonas
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
