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 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.)
> Dependency files are still a complication though, unless they're
> changed into a shell-sourceable format. Ideally it would be compatible
> with existing files though, so I guess that means using a comment. "#
> :gtk" for "when gtk is enabled"? That would let actual comments still
> exist, if they're useful to have.
Dependency files are currently parsed by Python code and it already
uses a custom syntax (with operators, etc.) -- extending it to put
flag information, annotation such as "optional", etc., is doable.
> 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.
> > > I also don't know how this would interplay with binary packages. So
> >
> > I think we should go the simple route there: for binary packages,
> > define a fixed set of use flags, and use them consistently in all
> > packages from the repository. If people want to tweak their system at
> > use flag level, then they should follow the ways of the source.
> Yes. But that does mean people will end up having to have all-binary
> or all-source systems, since there's no way to guarantee they'll be
> compatible. Gentoo does it that way; there are binary packages you can
> install provided you haven't changed your USE flags or compiled
> anything since initial installation. They would be useful as far as
> providing things that don't fit on the CD, but not much further.
Somewhat. Turns out that dependency chains between packages tend to
form "clusters", and often a user is interested in tweak part of their
system, but not the entire thing. For example, I might want to
recompile all my audio apps to use Jack, low-latency, etc., but I'd
still use GCC from the binary package. When using a package as a
dependency, comparing their flags to the flags being used can serve as
a good hint for compatibility. We might need to specify flags in
dependency files ("I need a libfoo compiled with the bar flag").
-- Hisham
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
