Re: Portability and distribution with Gtk+ 1.3

Thanks for the answers.

> With one substantial difference, which is reluctance to depend so much
> on the runtime environment (i.e. we are not expecting CORBA to work
> properly, there are not daemons such as oafd and gconfd, etc.)

Yes, definitely true.

> The basic fact is that most users want features such as image loading
> ("how do I load a JPEG?" is a huge FAQ on the lists) while relatively
> few users care much about dependency lists. So to the extent that
> there's a tradeoff, no it isn't going to be changed.

OK, I guess it is a matter of always requiring the dependencies, or having
a way to separate them. As far as I understand you welcome suggestions
to enable separation and such.

> Note that libpng is only used at compile time to run
> make-inline-pixbuf for example, so you could change the makefiles to
> run --make-inline-pixbuf at 'make dist' time perhaps, and distribute
> the generated files with the tarball. So then end users could build a
> zlib-free png-free gtk.

Interesting. Will see what can be done in this area.

> When it's missing, adding the equivalent of the
> --with-included-modules flag for these would be welcome.


> I believe you can build without pthread, if you pass the right stuff
> to glib configure.

The trouble is that I do not want to reconfigure/rebuild/reinstall glib
each time I build a new application that has or doesn't have threads.

Unless I am missing something, with Gtk+ 1.2, as long as you do not
use libgthread explicitely, you do not depend on libgthread not libpthread,
even when glib has been configured with --enable-threads
(the default I believe).

This is this change of behavior that I find annoying, but if it is an unwanted
change, it might be possible to fix/revert this change.

> Specific bug reports ( and fixes in this area would
> be good. We do want to support statically linked apps, but aren't
> necessarily aware of all the issues, so if you're working on this and
> can help point out all the specific stuff that comes up, it would be
> invaluable.

Understood. Of course, having more documents explaining what is the current
state, and what is expected would help, as there some work in the area
(done or in progress) ?

> To make linking statically "just work" I suppose we'd need to build
> the .a libs with everything included, and the .so libs with dlopened
> modules, I don't know if that's a good idea though. Seems like it
> might be confusing. You might experiment with getting automake/libtool
> to do this and see if it works well.

Well, having everything included in the .a will also mean that generated
executables will be huge, will is not a negligible point for statically
linked executables. I guess the --with-included* options address part of this
concern (even if again, this is a configure time option, which is not
very flexible since it is not practical to reconfigure and rebuild the
"Gtk world" again and differently for each application and on each target.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]