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.
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.
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 ;)
But I am slowly beginning to see some of the win32 problems.
> 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
It's just a matter of time for msvc to support C, though, so even this
difference will soon vanish (or so).
> corresponding printf format is obviously the same, though, as the C
True, but the commandline switches are not (just on of the problems we
have on irix, for example, as gimp-perl links against perl AND gimp, and
both worlds (perl/libtool) might have different ideas on how to do so).
> Wrong. Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of
> GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care
> either.
Hmmm.. what if perl tells me to link against c:\perl\perl.lib but gcc does
not like this on it's commandline?
> 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
you are pretty much tied to msvc for gimp as well. everything else will
end up in a ral nightmare, as you found out ;)
> (I think it was wrong to include dirent emulation in libmingw32, and a
> <dirent.h> header, as that breaks being able to compile the same code
> with either gcc or MSVC.)
I also think it was bad for PDL to include the ppport.h header file, as
gimp-perl does the same ;-> What's even worse is the config-trickery I do
in the makefile to increase the chances of libtool and perl coexisting. It
*is* a crual world, even under unix....
> 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%.
Extra prizes if the Perl-Server will run (it uses unix domain sockets ;),
but that one is not required either.
> > 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? ;) Whew.
> to look into it. One problem I can think of right now is that the gimp
> modules want to use entry points in the gimp executable, and for that
Given that the next version of gimp might make extensive use of modules,
this will be a problem.
> building the exe. I.e. build the exe kinda like you would build a DLL.
> There is no mechanism in auto* or libtool to handle that, I think.
Ah, so the tools you switch *to* lack the support to do what you need ;) A
cruel world.
My personal problem with libtool (and to a lesser extent automake) is
that tehy are *very* narrow-minded. They insist on the smallest possible
subset. For example, I often want to build shared libraries without
-fpic since this works under any platform I care for. It doesn't allow
this. What's even worse, I often just *know* that I can link against that
libperl.a file but libtool refuses because it simply will not link against
.a files.
> It now seems as it indeed would be easier to use a Perl running on
> cygwin to produce the Makefiles for Gtk-Perl and Gimp-Perl (Makefiles
> for GNU Make and a cygwin shell), but still have those Makefiles run
> the mingw gcc. (That's the kind of Makefiles I build GLib, GTK+ and
> GIMP with.)
All that's needed would be a perl ported to mingw32. As I udnerstand it,
mingw is just a gcc that threw away POSIX and gives you a "standard" win32
build environment.
So what is needed is a perl that expects the windows environment and a
unix build environment. On CPAN I cna only find the "standard" (a.k.a.
"perl") and "activestate" ports. 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.)
This port currently supports MakeMaker (the set of modules that is
used to build extensions to perl). Therefore, you should be able to
build and install most extensions found in the CPAN sites. See L<Usage
Hints> below for general hints about this.
I think thsi sounds like the right perl to use. IT can also be configured
for different make flavours.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
