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.
>
> > 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.
> > 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? 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).
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.
I guess that this would also make all enabled dependencies mandatory,
which was another issue that came up a while back.
> > 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.
-Michael
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
