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: A decouvrir
Sorry, I am linux.tnfsh.tn.edu.tw server administer. There is no [EMAIL PROTECTED] here. I don't know why he can send mail use this. Jirong.
Re: the Gimp 1.2.0 for windows ?
On 5 Jan, Bennett Keith Portnet wrote: Sorry to bug you, I found you name and email address in the GIMP files ! I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows. It has been uncompressed into a file on my hard drive. (I am running Windows NT) NOW WHAT DO I DO TO GET IT RUNNING ? I can't find a file that runs it ! No idea, I have no Windows. I'll forward this mail to the developpers mailinglist. Maybe someone knows an answer -- Servus, Daniel
Re: how to use *.pfb-fonts?
On Thursday 01 January 1970 01:00, Miles O'Neal wrote: Did you read through the FAQ, and follow the directions there for getting the fonts to work? http://www.rru.com/~meo/gimp/ I can't find the information there. However it seems now that I can use most of them. Max Moritz Sievers
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: A decouvrir
I got the same message with my domain name attached to the end. Very strange. chris -- Chris the Christianfreak http://christianfreak.com BE ALERT (The world needs more lerts...)
Re: A decouvrir
Hi Chris, I got the same message with my domain name attached to the end. Very strange. The sender didn't give a domain name at all and so yours is automatically inserted by your mail transfer agent. Greetings, Andy -- Andreas Jaekel, CableCats - Foest, Jaekel, Tegethoff GbR http://www.cablecats.de Tel.: 030 - 916 11 77 3
Re: the Gimp 1.2.0 for windows ?
Hi Bennet, maybe you did not pick up the right file. You need the file gimp-setup-20001226.zip. This will unzip to a single file gimp-setup-20001226.exe . Start this file to start the installation. --Peter [EMAIL PROTECTED] wrote: On 5 Jan, Bennett Keith Portnet wrote: Sorry to bug you, I found you name and email address in the GIMP files ! I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows. It has been uncompressed into a file on my hard drive. (I am running Windows NT) NOW WHAT DO I DO TO GET IT RUNNING ? I can't find a file that runs it ! No idea, I have no Windows. I'll forward this mail to the developpers mailinglist. Maybe someone knows an answer -- Servus, Daniel -- Peter Kirchgessner http://www.kirchgessner.net mailto:[EMAIL PROTECTED]
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 | |
Another Lead Special!!
Lead Special!! After Christmas Prices!! Pre-Qualified Prospect For Your Business!! http://www.geocities.com/lgbleads4ever/redirect1.htm
