(See the end of message for Perl-relevant stuff, mostly digression first...)
On Fri, Jan 05, 2001 at 02:44:42AM +0200, Tor Lillqvist <[EMAIL PROTECTED]> 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
