On Fri, 28 Feb 2003 16:11:46 +0100, <pcg@xxxxxxxx ( Marc) (A.) (Lehmann )> wrote: > On Fri, Feb 28, 2003 at 01:53:59PM +0100, Raphaël Quinet <quinet@xxxxxxxxxx> wrote: > > Even if the problems were only due to the build/install process, I > > think that it would be appropriate to say that "gimp-perl is broken". > > The result is that it is not possible for some users to use gimp-perl. > > And although gimp-perl works for most people in the 1.2.x releases, > > this is not the case for GIMP 1.3.x, in which gimp-perl is really > > "broken". I am not blaming you for that, but the current version is > > simply not working. > > Sorry, but your definition is simply useless. Gimp itself (and any > other software package) does not work for many users, and calling every > software package "broken", while, according to your definition, would be > true, is simply not useful. It really makes no sense to define "broken" > as "every software package in existence". If people would use such a > useless definition they would have no way of talking about "really" broken > software, since the word "broken" would have no information content > whatsoever. Well, OK, this is a rethoric issue. But this part of my comment started with "Even if the problems were only due to...". The other part of my comment was about GIMP 1.3.x. This is the part in which Gimp-Perl is really "broken" because nobody can use it. Although the last stable version is still GIMP 1.2.3 (soon 1.2.4), we are having this discussion on the developers' mailing list so I would expect that most subscribers care about the status of the current version, which is GIMP 1.3.x (or CVS HEAD). GIMP 1.3.x will hopefully become the next stable relase during this year, and it does not have a working Gimp-Perl yet. > > other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl > > while compiling or linking Perl modules because the compilers are > > different. > > Well, this is obviously a configuration problem on the system in > question. Nobody would assume that it should work to link windows dlls > together with glibc and get something useful out of it, or configure > gimp with compiler switches the compiler can't understand. The fix is to > fix the configuration. Nothing is broken, it all works fine if the build > environment is non-broken. This issue is not as simple as you make it look like. It may be possible (but not necessarily easy nor elegant) for the Gimp-Perl Makefile to switch compilers and compiler flags depending on what part of the code is being compiled. Using always the compiler flags provided by Perl is not necessarily a good idea, especially if the user does not have access to the compiler that was used for compiling Perl. This may require some tricks (such as extracting the right flags for -I, -L and so on) but it may solve some of the problems as long as the object files from different compilers can be linked together. Also, I could also argue that your definition of a "non-broken" environment is a bit too strict. Except for Perl modules, there are no problems in compiling and linking some software with libraries produced by different compilers. It's not as if we were trying to link windows dlls and glibc together: here we are talking about linking object files and libraries that are designed for the same platform and use the same basic format (ELF, for example). So for many people (again, mostly on non-Linux platforms), Gimp-Perl is the part in which the GIMP build process breaks. The other plug-ins depend only on simple libraries such as the JPEG or PNG libraries and there are usually less problems with that (regardless of the compiler used). As I wrote in my previous message, this problem is due to the way Perl modules are built and it is not specific to Gimp-Perl. The same problems can also occur when trying to build mod_perl for Apache, for example. It may be possible to implement some hacks in Gimp-Perl that allow it to work regardless of the compiler used, but this will not be easy. > > Another problem is for non-root users who install everything in a > > to the Perl directories. It is possible to avoid these problems by > > building and installing a second version of Perl or by installing the > > It's also possible to avoid this problems by setting the prefix, nothing > complicated like you say is neccessary. Yes, that's what I mentioned in the next line of my reply (which you unfortunately forgot to include in your quote): it is possible to install the modules in a separate directory, but then you have to make sure that it appears in @INC. So you may have to set the environment variable PERL5LIB. [...] > > > confusion and misinformation going on... > > I don't think that it is intentional. > > Well, maybe not, but I am pretty sure that your claiming that everything > is broken is not helping users. I understand your frustration about this. Anyway, I hope that you will be able to solve the problems with Gimp-Perl in CVS. -Raphaël
