On Fri, 28 Feb 2003 16:11:46 +0100, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote:
> On Fri, Feb 28, 2003 at 01:53:59PM +0100, RaphaŽl Quinet <[EMAIL PROTECTED]> 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
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
> > 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
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
> > > 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.
Gimp-developer mailing list