Re: perl script in gimp for Windows : is it possible ?
(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
Re: perl script in gimp for Windows : is it possible ?
At 01:07 05.01.01 +0100, Marc Lehmann wrote: - ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a Makefile for nmake, that uses cl to compile and link to link. Oh well, that is not so bad in itself, I have MSVC available at work, and, ehh, I might have a copy at home also. This is, of course, not solvable in any case. Changing the compiler means that all the autodetected stuff goes wrong. This also means that the compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the same. We have a lot of problems with this (obvious for me but not others it seems), e.g. on IRIX where the preinstalled perl is compiled with the commercial sgi compiler but most people only have access to gcc (which is not compatible). At least the win32 "C" compilers are exchangeable quite well (even gcc has learned to use -fnative-struct). Though there probably will arise problems with different posix emulations. Mixing allocators between binaries from different compiler (c-runtimes) does no good as well ... The common case to build gtk+, etc. on win32 are hand-written makefiles. #defines and stuff to hide the GLib versions. Unfortunately there are lots of those .xs files that need to have the same stuff inserted. Oh well, just manual work. The better option IMHO would be to make glib (source available!) compilable against perl, as a compatibility measure on win32. I am not sure qwether sources for activestate's port are available and even if, it requires a non-free compiler. Although Perl may rule the world, I would rather appreciate to not make glib and all Perl compatible, but go the other way around, if any. [...] Maybe it would be better to use a Perl running on cygwin? That would help a couple of the issues above. Certainly. Also not concentrating on gtk-perl but instead on gimp-perl would also help. But wouldn't gimp-perl without gtk-perl loose most of it's charme ? [...] OTOH, the main gimp makefile also uses test and a lot of unix-things. Is gimp not build using autoconf on win32? Nope. See above. and make sure I am not duplicating somebody else's work in progress, and to ask if he has done any more work on Gtk-Perl since 0.6123. (This There was, however, I am quite sure nobody ever tried to port it to win32. At least not to a non-unix-like target (mingw32 or msvc). I have tried, but it's so long ago, that I would need to search my backups to see what problems finally stopped it. If I recall correctly: I got that far, that the main problem was a crashing MSVC compiler. At that point I decide to port pygtk and pygimp instead. BTW: They are available at http://hans.breuer.org/ports (I am not promising that I will hack any more on Gtk-Perl on Win32 anytime soon...) [...] At the moment the most promising approach appears to write a generic perl to python translator :-) Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: perl script in gimp for Windows : is it possible ?
On 01/05/01 Marc Lehmann wrote: [Note: I CC:'ied this as well as tor's original mail to the current gtk maintainer, which is Paolo Molaro [EMAIL PROTECTED]] I didn't get the original mail from Tori, but I got it from the archive anyway... The most difficult one would indeed be activestate (the dominant perl), since activestate is ported closely to windows (it is the "better" port in that sense) and all of the extension problems (e.g.) get real, although the makefiles that perl itself generates should be fine. Using the same compiler for perl, gtk+ and gtk/perl is the first step to narrow down the possible compilation problems - Makefile.PL wants to use gtk-config. No such on Win32. (How could there be one? On Win32, people typically don't build GTK+ themselves, but fetch the headers and libraries The same, of course, is true for the gimp. most people who build gimp would be able to build gtk as well ;) In any case, gtk-perl does, indeed, use a lot of unix functionality so building that one without cygwin will require !CHANGES!. Yep, cygwin should be the easiest route, though I don't know if it has other issues (I don't use windows and don't plan to to try it out:-). That said, I'll integrate the patches needed to make it work, just make them against cvs HEAD (module gnome-perl in the gnome cvs). - ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a Makefile for nmake, that uses cl to compile and link to link. Oh well, that is not so bad in itself, I have MSVC available at work, and, ehh, I might have a copy at home also. This is, of course, not solvable in any case. Changing the compiler means that all the autodetected stuff goes wrong. This also means that the compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the same. We have a lot of problems with this (obvious for me but not others it seems), e.g. on IRIX where the preinstalled perl is compiled with the commercial sgi compiler but most people only have access to gcc (which is not compatible). Most of the command line options and command names can be changed using makefile variables, but it's a pain neverless. #defines and stuff to hide the GLib versions. Unfortunately there are lots of those .xs files that need to have the same stuff inserted. Oh well, just manual work. The better option IMHO would be to make glib (source available!) compilable against perl, as a compatibility measure on win32. I am not Seconded: maybe check if perl on win32 includes a #define for opendir or something like that and conditionally #define the symbols in glib.h. sure qwether sources for activestate's port are available and even if, it requires a non-free compiler. - Some X11-backend specific stuff present in Gtk-Perl. Have to #ifdef those out, but in a way that is still compatible with GTK+ 1.2, which didn't have several backends, and doesn't define GDK_WINDOWING_X11. Gtk-Perl also uses some GDK functions that don't exist any longer. At this point I bailed out again... I have better things to do, like, eh, sleep? If you have patches, I am quite sure the gtk-perl people will be very intereste din them, even if they only partially solve the problem by making it compile for example. Yep, please send me the patches you have. I have been requested several times about gtk-perl for windows, but no one ever sends patches:-) I don't use windows, but I'd love gtk-perl working on win32! (I am not promising that I will hack any more on Gtk-Perl on Win32 anytime soon...) Every step brings us closer to the target:-) Please do contribute your changes so that someone else doesn't have to redo them if you don't have time to continue working on it. Thanks! lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: perl script in gimp for Windows : is it possible ?
On Fri, Jan 05, 2001 at 11:13:00AM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote: 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?". (c:\gnu\gtk+ required ;) If it only was so easy... I can easily imagine that a potential GTK+ But wouldn't it be possible to make a gtk-config.bat? Given the estristcion to use the same compiler as used to build gtk+ this should be easily doable. 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.) The problem is that the compilers themselves are not compatible: - msvc lacks good C support (long long), so perl might define I64 as __long or something which gcc might glady ignore :( - gcc uses different commandline syntax, so whatever gtk-config outputs might not be soemthing that the compiler likes. OK, great. I will first try to get Gimp-Perl running without Gtk-Perl then. Just hammer bugs on me and I'll (try to) fix them ;) Thanks! 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. No, I can't, although I heard that the fork-emulation would be slow. However, running configure for gimp on unix takes too long, so but usually my machine is too slow ;) (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?) Well, perl modules use whatever they are told by ExtUtils::MakeMaker, which could be abused to do cross-compiling. But just like configure, most modules will want to run the resulting exectables, which is not possible with a cross compile, so it WILL be easier to not even try it. But mingw32 + cygwin (for the shell utils only) should work, no? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: perl script in gimp for Windows : is it possible ?
Marc Lehmann writes: - Makefile.PL wants to use gtk-config. No such on Win32. (How could there be one? On Win32, people typically don't build GTK+ themselves, but fetch the headers and libraries The same, of course, is true for the gimp. most people who build gimp would be able to build gtk as well ;) gtk-config (or glib-config) is not a problem for people who *build* glib and/or gtk+ themselves, they know where they are going to install it, and they could generate a suitable *-config script. The problem is 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. This is, of course, not solvable in any case. Changing the compiler means that all the autodetected stuff goes wrong. It isn't necessarily that bad, remember that mingw and MSVC use the same runtime, and all header files that are present in MSVC have clones in mingw. Most autodetected stuff is equally valid for mingw 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 corresponding printf format is obviously the same, though, as the C library is the same.) This also means that the compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the same. 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. We have a lot of problems with this (obvious for me but not others it seems), e.g. on IRIX where the preinstalled perl is compiled with the commercial sgi compiler but most people only have access to gcc (which is not compatible). On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is another matter). The bleeding edge of binutils (which I personally don't use yet) can even link to DLLs directly (autogenerating import libraries on the fly), or use libraries in MS's format. The better option IMHO would be to make glib (source available!) compilable against perl, as a compatibility measure on win32. Yes, the dirent emulation is GLib has caused some problems before, as it isn't the same emulation as that in the libmingw32 library (which the mingw gcc automatically links with). I will probably move the dirent stuff out to a separate library (so that it is available for MSVC users), and make it identical to the one in libmingw32. (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.) Certainly. Also not concentrating on gtk-perl but instead on gimp-perl would also help. I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl is a prerequisite. OTOH, the main gimp makefile also uses test and a lot of unix-things. Is gimp not build using autoconf on win32? Nope. This most likely will change at some point when I have the time 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 to work on Win32 you must mark those entry points for export when 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. 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.) --tml
Re: perl script in gimp for Windows : is it possible ?
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 LUsage Hints
