Re: libgtk-dev bug?
David Huggins-Daines <firstname.lastname@example.org> wrote:
> > This means that, if you install something in the middle of a build,
> > you won't have a consistent configuration. That means that you can't
> > safely share a machine which is compiling these kinds of programs.
> Yes, but if you install new headers and shared libraries on a machine
> while compiling, you won't get consistent results either ;-) But
> maybe I don't quite understand what you're saying here...
Well, imagine that Gtk used curses, and was being compiled against
ncurses when someone installs termcap compat. Or imagine if it
were being compiled on a machine without sound support and then
someone went ahead and installed sound support. Or any other
significant configuration choice which reflects the availability of
some external piece of software.
> > Doesn't look like a fatal flaw, though: you can easily cache the
> > result from gtk-config. [Or can you? I've not mucked around with
> > these
> If you use the standard AM_PATH_GTK macro, its output gets cached by
> the configure script. Or at least it seems so, since I have to make
> distclean and reconfigure --with-gtk-path=/usr/local if I want to
> compile against GTK+ 1.1 (/usr/local/bin/gtk-config) instead of 1.0.4
> (/usr/bin/gtk-config) on my system.
That's not conclusive evidence, but it is promising.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org