(See the end of message for Perl-relevant stuff, mostly digression first...) On Fri, Jan 05, 2001 at 02:44:42AM +0200, Tor Lillqvist <tml@xxxxxx> wrote: >> producing a glib-config or gtk-config for people who download the >> headers and prebuilt libs (in a zipfile), and install them in some >> random place, and then would like to build some application. Marc writes: > Well, I thought that people capable of building gimp (in win32 this is not > common ;) could build gtk+ as well, but in general (when gimp for win32 is > being built by millions of users wordlwide) this is a hindrance. Umm, I didn't mean that there were more people building GIMP themselves that people building GLib or GTK+. But there are a number of people who don't care building GLib or GTK+, but do want to build *other* GTK+ applications. They are the the ones that sometimes ask "where is gtk-config?". > However, when it is possible to create downloadable binary distributions > for linux it should not be that difficult to do so for windows as well > (c:\gnu\gtk+ required ;) If it only was so easy... I can easily imagine that a potential GTK+ developer which uses different workstations each day doesn't want to put anything on any C: drive, but instead in his home directory, which could be something simple like H:\, or complex like \\redmond42\lusers\b\billgates. >> and MSVC. (One difference is that gcc uses long long and the LL suffix >> for long long literals, MSVC uses __int64 and the i64 suffix. The Of course, in GLib- and GTK+-using code one should use G_GINT64_CONSTANT, so the point is moot anyway. > It's just a matter of time for msvc to support C, though, so even this > difference will soon vanish (or so). You mean "to support C99"? Probably. I should check the (free beer) beta of the next MSVC that is said to be included with the .NET (sheesh) SDK. >> On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is > yes, but msvc isn't and when you pick, e.g. activestate as your perl then Umm, huh? Gcc-produced code (from C source) is binary compatible with MSVC-produced. (As long as you use the -fnative-struct switch to gcc.) >> I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl >> is a prerequisite. > No. gimp-perl will detect (not using autoconf this time) wether Gtk is > installed and will not try to do anything graphically if it isn't. This means > thast many scripts will run with default values (somewhat useful) and the > ones depending on Gtk will not be instaled, but scriptability is still 100%. OK, great. I will first try to get Gimp-Perl running without Gtk-Perl then. > > > OTOH, the main gimp makefile also uses test and a lot of unix-things. Is > > > gimp not build using autoconf on win32? > > Nope. > Now that's cool! Is that an art form? ;) More like a form of masochism. Actually, it is easier in a way to keep manually written makefiles up-to date than struggling with auto*, configure, and libtool on Win32. At least it's much faster. You can imagine how slowly auto* and libtool run on Win98, or cygwin hosted on Win98 even. All those sed, awk, test etc invocations do slow it down. (It is especially irritating to wait for a configure run to finish when you consider that one already *knows* what the result of all the frigging checks configure is running will be. It is not like the features in Win32 and MS's C runtime would change under you between configure runs.) But anyway, I do realise that the Right Thing is to use the normal configuration mechanism, and will move to it, eventually. > As I understand it, mingw is just a gcc that threw away POSIX and > gives you a "standard" win32 build environment. It is a bit debatable what mingw is. Personally I would define it as simply gcc and binutils running on Win32, producing code for Win32, with no cygwin or other POSIX emulation in sight. Some people talk about a "mingw runtime" but I don't like that, mingw-produced apps should and do work just like MSVC-produced ones, they don't use any "mingw runtime". > I looked at the "standard" README.win32 > and it seems to be a truely native port, it works with borland, msvc AND: > Mingw32 with GCC version 2.95.2 or better > The last of these is a high quality freeware compiler. Support for it > is still experimental. (Older versions of GCC are known not to work.) > I think this sounds like the right perl to use. Indeed. I will switch... (PS. When I considered using a Perl running under cygwin, I was on the wrong track. Cygwin is its own operating system in a way, so using cygwin-hosted tools to build for Win32 is a cross-compilation. It isn't possible to cross-compile Perl modules, is it?) --tml
