Ok, I think we are converging:
On 5/6/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> 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:
> >> >> 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".
Yes, we don't want flags to be too app-specific. "with_gtk" is good,
"without_gmplayer" is bad.
> >> >> 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?
Often it's just because we don't want it, sometimes things break. The
binary for MC compiled with X11 support refuses to load on systems
where X11 is not installed.
> > 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.
In the end they're equivalent, assuming that installing GTK+ enables
the "gtk" flag by default.
> 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'.
Agreed, flags should be general. But they can be specific in some
cases. It's a matter of making a good balance, I think we can do it.
It's more a matter of how we'll use the flags, rather than how we'll
implement them.
> >> >> >> 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.
Like you said, we can't provide a way for users to do any possible
tweak to the compilation. Ultimately, the way to do that is editing
the recipe (which is at least equivalent in terms of end-user
complexity to giving command-line options for everything that could be
tweaked). Use flags are about convenience and making it easier to
apply "major tweaks" ("I want to use PAM") consistently.
> >> >> >> 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.
Roughly, we "kinda have" choosing what dependencies a user wants to
install now. It's about adding a layer of abstraction on top of that.
> >> > 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?
For "major tweaks", use-flags; for uncommon tweaks,
--configure-options or editing the recipe (personally I prefer editing
the recipe, so I can keep in my local recipes tree the tweak
"documented").
-- Hisham
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
