On Fri, Feb 28, 2003 at 08:05:04PM +0100, RaphaÃl Quinet <quinet@xxxxxxxxxx> wrote:
Please don't call this rethorics - if you do, you are measuring different
things differently, which is not at all fair.
> 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.
Actually, we were having this discussion with somebody who uses gimp-1.2,
and for whom gimp-perl _does_ work, as much as you can expect, that is.
gimp-developers is IMHO well-suited for discussion about gimp-1.2,
otherwise there would be no forum for bugfixes etc. with respect to
gimp-1.2, and people certainly do care about fixing bugs and devloping
gimp-1.2 into an even more stable form.
> 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.
On IRIX, it isn't (compilers _are_ link-incompatible). On other platforms
you will find that just switching compiler flags won't help, as perl uses
different versions of it's macros depending on compiler and configuration,
and will not work properly no matter what.
And I don't at all think it's reasonable to get this to work anywhere,
since, if NO perl module can be compiled, then the right place to fix it
is not in gimp-perl, but in the general configuration (And it's easy, just
supply your own version of perl that is capable of compiling and linking).
I mean, I simply don't see why a perl module should be able to reconfigure
an already instaleld perl on every possible configuration, when this
configuration step is done by perl already - duplicating it is just a
maintainance nightmare, and won't help other modules. I mean, it's way
easier to just ship perl together with gimp and always use it's own
version....
> 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.
Well, if _no_ perl module (that uses non-perl code) can be installed on
that environment, I think it's "broken", in the sense that you can't build
perl modules.
It's still way less strict than your definition of broken, though.
> 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).
No, we are talking about _source_ configured for a particular compiler
and things like building dynamic objects, which is not very common
(it's not the same as building a shared library, for example), and
certainly differes a lot between platforms. Especially when you find
that some platforms have funny dependency issues regarding which shared
library is linked with which dynamic object to which binary. HPUX is the
prime offender, but even "sane" ELF machines like IRIX all need various
compiler-specific workarounds (not to mention n32 vs. n64 vs....).
> So for many people (again, mostly on non-Linux platforms), Gimp-Perl
> is the part in which the GIMP build process breaks.
Yes, so gimp is broken (according to your definition). However, the same
logic applies to a compiler that cannot compile gimp because it requires
pre-iso-c89 or has bugs that keep it from working.
In any case, it's not reasonable to be able to build gimp-perl with a
perl that isn't able to build any modules. No matter how you argue, I
fail to see why this should be different - if a user cannot supply a
working perl, he should --disable-perl or ask thed evelopers to try and
_detect_ this case and diable it.
The expectation to make a perl module work with a broken installation of
perl (which I define as: perl modules can't be build because the compiler
is missing) is and will always be unreasonable.
Mind you, I have IRIX and hpux machines, and gimp-perl _works_ _fine_ on
them. So your claim that users can't use it on these machines is wrong.
You just have to provide the build environment to build perl modules, and
if you don't have the compiler, then provide gcc and a perl that works
with it.
Especially on irix, where the bundled perl is old and doesn't work
properly with many of irix' own scripts.
> plug-ins depend only on simple libraries such as the JPEG or PNG
Yes, perl is not a library at all. it's rather big and rather optimised
for it's build environment.
For example you wouldn't expect to be able to link with a libjpeg if
you used a different header file than the one supplied (it checks for
structure sizes etc. at runtime, but it's no fun).
> 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.
It really is not feasible on most platforms (exceptions probably do
exist), and a much easier fix is available: just fix your perl, or don't
use gimp-perl.
> > 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.
Well... What do you expect? That perl does a "find /" and looks for
modules everytime it is run? If you want to be funny and move files
around then you should be happy if you cna get it to work.
I mean, what you are talking about is the same as moving gimps library
files to a completely different location without gimp telling it - is it
really possible? (Just for a test, move the scripts and libgimp* away and
check).
It's simply not reasonable to have this working magically. If youc all
it broken then, please, apply the same deifnitino to gimp or other
projects - I am sure you will find out nobody will share your peculiar
definition of broken.
Mind you, my problem is telling people who have a working gimp-1.2 + a
working gimp-pelr that gimp-perl is "broken". That's not a big disservice
to these people, as it doesn't help them.
> I understand your frustration about this. Anyway, I hope that you
> will be able to solve the problems with Gimp-Perl in CVS.
As I said, I don't think I will work with the gimp in cvs anymore, but I
sitll plan to support gimp-1.4 with gimp-perl (most probably by using the
Gtk module with gtk-1.2).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
