Re: [gobolinux-devel] USE flags & Xorg
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:
> > > > My main comment is to reiterate that USE flags are welcome. I have an
> > > > abstract sentiment that part of it could be automated with optional
> > > > dependencies (ie, "don't build the GTK+ interface if I don't have GTK+
> > > > installed") but I don't have a concrete image of how everything would
> > > > fit together implementation-wise.
> > > That would be useful too - but it doesn't help for hardware-required
> > > programs (unless you examine /proc/config.gz really closely, and
> > > that's likely to be difficult to do flawlessly).
> >
> > I didn't think about going this far; I agree it's probably not worth the
> > effort.
> >
> > > 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.
> >
> > > There would still need to be another, parallel system to deal with the
> > > other situations, and a way to disable the flags created this way. I
> > > don't know whether that would be more trouble than it's worth; it
> > > might be confusing to have behaviour changes because of an unrelated
> > > install.
> >
> > Right.
> >
> > > 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
> >
> > A flag to compile overriding the system useflags? As in
> > Compile foobar --with gtk --without qt
> > where --with and --without are lists of useflags.
> I'd prefer things to be automatic as far as possible, so that things
> don't end up broken because you forgot to use the same flags this
> time.
Yeah. I was thinking about the case when a user wants to do a one-off
change to their usual set of flags.
> > > that. Gentoo uses text files; we might prefer a filesystem-based
> > > approach. I would quite like to have some way to find out which
> > > programs were compiled with which flags, in both directions. That
> >
> > The set of used flags at the time of compilation could be stored in a
> > Resources/ file.
> > But what do you mean by both directions?
> In the sense that it would be simple to get a list of everything
> compiled with flag X on, so you could find out what to recompile if
> you turned it off. You could just search through all the Resources
> files, but that's not really reasonable when there are hundreds of
> them. Of course, it could just be that that's the domain of another
> tool and it really does work that way.
I see. Anyway, scanning 200 Resources files is not *that* much work,
anyway. Tools could do that, and with a little caching it would work
nicely.
> > > could be symlinks, I'm not sure whether it'd ever actually be useful
> > > to traverse a tree like that.
> > >
> > > Post-014 I would like to put some work into getting something like
> > > this up and running; the specifics of which method would be best I
> > > don't know. My original idea had dependency files like `Flag_On i810
> > > && require XF86-Video-i810 1.7.4`, and similar functions for adding
> > > configure parameters in the recipes, but I think that might get a
> > > little ugly for something complicated. It's probably necessary on the
> > > recipes' side, since things could get arbitrarily complicated there.
> >
> > A number of proposed implementations floated around in the list over
> > the years (IIRC, one from Carlo, one from Andreas Koehler, and even
> > one mine if I'm not mistaken) and they were all variations on this
> > basic theme. Right now I think for Compile the cleanest would be to
> > have "sections" (actually shell functions) like this:
> >
> > using_gtk() {
> >add_flag configure_options "--with-gtk"
> >something_else="foo"
> > }
> > not_using_ssl() {
> >add_flag configure_options "--without-ssl"
> > }
> >
> > We could have smart functions to cover common cases such as "when
> > using gtk, add --with-gtk, but remove it otherwise":
> >
> > when_using_gtk configure_options "--with-gtk"
> That is very slick. I like it. What about situations that require
> testing multiple flags?
I think we could come up with these features as the needs arise, but
with some general functions basically everything could be solved
programatically. I think functions like described above would be
prettier but something like:
if using ssl && not_using kerberos
then
something=foo
fi
would work too. (The idea of recipe files degenerating into shell
scripts is a painful one though. I'd rather have shell code limited to
the interior of functions, like
using_ssl() {
not_using kerberos && something=foo
}
to keep recipes more "statically verifiable" (in other words, to make
RecipeLint's life easier).
> It's not really plausible to have functions
> for every com
Re: [gobolinux-devel] USE flags & Xorg
On Fri, 04 May 2007 21:42:14 +0200, Hisham Muhammad <[EMAIL PROTECTED]> wrote: > 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: >> > > > My main comment is to reiterate that USE flags are welcome. I >> have an >> > > > abstract sentiment that part of it could be automated with >> optional >> > > > dependencies (ie, "don't build the GTK+ interface if I don't have >> GTK+ >> > > > installed") but I don't have a concrete image of how everything >> would >> > > > fit together implementation-wise. >> > > That would be useful too - but it doesn't help for hardware-required >> > > programs (unless you examine /proc/config.gz really closely, and >> > > that's likely to be difficult to do flawlessly). >> > >> > I didn't think about going this far; I agree it's probably not worth >> the effort. >> > >> > > 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 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. >> > > There would still need to be another, parallel system to deal with >> the >> > > other situations, and a way to disable the flags created this way. I >> > > don't know whether that would be more trouble than it's worth; it >> > > might be confusing to have behaviour changes because of an unrelated >> > > install. >> > >> > Right. >> > 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. >> > > 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. >> > A flag to compile overriding the system useflags? As in >> > Compile foobar --with gtk --without qt >> > where --with and --without are lists of useflags. >> I'd prefer things to be automatic as far as possible, so that things >> don't end up broken because you forgot to use the same flags this >> time. > > Yeah. I was thinking about the case when a user wants to do a one-off > change to their usual set of flags. > We still have '--configure-options', which I think we should save somewhere, when the user specifies his/her own settings for an application. Flags should be system wide, like '--use-gtk', '--prefer-gnutls' (over OpenSSL) etc. For controlling applications '--configure-options' should be used. >> > > that. Gentoo uses text files; we might prefer a filesystem-based >> > > approach. I would quite like to have some way to find out which >> > > programs were compiled with which flags, in both directions. That >> > >> > The set of used flags at the time of compilation could be stored in a >> > Resources/ file. >> > But what do you mean by both directions? >> In the sense that it would be simple to get a list of everything >> compiled with flag X on, so you could find out what to recompile if >> you turned it off. You could just search through all the Resources >> files, but that's not really reasonable when there are hundreds of >> them. Of course, it could just be that that's the domain of another >> tool and it really does work that way. > > I see. Anyway, scanning 200 Resources files is not *that* much work, > anyway. Tools could do that, and with a little caching it would work > nicely. > Resource file is ok, but to provide readability, shouldn't configure options used be there as well, not just flags. After all, users shouldn't have to use tools to find out information about an application in GoboLinux. >> > > could be symlinks, I'm not sure whether it'd ever actually be useful >> > > to traverse a tree like that. >> > > >> > > Post-014 I would like to put some work into getting something like >> > > this up and running; the specifics of which method would be best I >> > > don't know. My original idea
Re: [gobolinux-devel] USE flags & Xorg
On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > On Fri, 04 May 2007 21:42:14 +0200, Hisham Muhammad <[EMAIL PROTECTED]> > wrote: > > > 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: > >> > > > My main comment is to reiterate that USE flags are welcome. I > >> have an > >> > > > abstract sentiment that part of it could be automated with > >> optional > >> > > > dependencies (ie, "don't build the GTK+ interface if I don't have > >> GTK+ > >> > > > installed") but I don't have a concrete image of how everything > >> would > >> > > > fit together implementation-wise. > >> > > That would be useful too - but it doesn't help for hardware-required > >> > > programs (unless you examine /proc/config.gz really closely, and > >> > > that's likely to be difficult to do flawlessly). > >> > > >> > I didn't think about going this far; I agree it's probably not worth > >> the effort. > >> > > >> > > 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 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. It would still be necessary to have a way of setting independent flags to cover the original case I brought up: there's no "i810" or "Cyrus" program to look for to see whether to compile support for the appropriate video card. > >> > > There would still need to be another, parallel system to deal with > >> the > >> > > other situations, and a way to disable the flags created this way. I > >> > > don't know whether that would be more trouble than it's worth; it > >> > > might be confusing to have behaviour changes because of an unrelated > >> > > install. > >> > > >> > Right. > >> > > 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. Ideally as much of it as possible would happen by magic for the common case, so you wouldn't actually have to do anything. > >> > > 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. > >> > A flag to compile overriding the system useflags? As in > >> > Compile foobar --with gtk --without qt > >> > where --with and --without are lists of useflags. > >> I'd prefer things to be automatic as far as possible, so that things > >> don't end up broken because you forgot to use the same flags this > >> time. > > > > Yeah. I was thinking about the case when a user wants to do a one-off > > change to their usual set of flags. > > > We still have '--configure-options', which I think we should save > somewhere, when the user specifies his/her own settings for an application. > > Flags should be system wide, like '--use-gtk', '--prefer-gnutls' (over > OpenSSL) etc. For controlling applications '--configure-options' should be > used. Broadly, yes, but I would still like things to be automatic wherever possible, rather than relying on people doing it the same way manually every time. People will forget, and it'd be a pain to have to look them up each time. > >> > > that. Gentoo uses text files; we might prefer a filesystem-based > >> > > approach. I would quite like to have some way to find out which > >> > > programs were compiled with which flags, in both directions. That > >> > > >> > The set of used flags at the time of compilation could be stored in a > >> > Resources/ file. > >> > But wha
