Re: [Gimp-developer] Patch: binary relocatability support for Gimp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Hongli Lai <h.lai@xxxxxxxxx> writes:

> On Win32, Gimp is relocatable. It can find out it's own path at
> runtime and find out where it's data files are. On Linux, all paths in
> Gimp are hardcoded at compile time. This means the app is not
> relocatable.
> 
> I work for the autopackage project (http://autopackage.org/), a new
> installation system for Linux. One of the features of autopackage is
> that packages can be installed to any prefix (although that's not
> recommended), which means the software must be relocatable. Because
> there's no real easy way to quickly find out the path of a library or
> application.
> See also http://autopackage.org/docs/binreloc/ for more info about
> BinReloc and the relocation problem.
> 
> Anyway, to the point. I'm packaging Gimp 2 currently and I've modified
> Gimp to be relocatable on Linux. The patch is mostly finished but
> there are still minor issues to take care of. I'd like to know if this
> patch is good enough to be able to get accepted, and if not, why.
> 
> Please note that adding binary relocation support on Linux will not
> harm portability! I wrote a configure check for this, and binary
> relocation support will be automatically disabled if the system is not
> running on Linux. The user can also explicitly tell configure to
> disable binreloc support.
> 
> I am aware that app/main.c sets LD_LIBRARY_PATH. This is just
> temporary because it's less work than modifying every Makefile for
> every plugin. Apart from this obvious hack, how does the rest of the
> patch look? Is it good enough to be accepted once I remove the
> LD_LIBRARY_PATH hack?

No. Your patch does not follow the GIMP coding style, breaks file
naming conventions and duplicates code available in GLib. So we will
not accept the patch as is. But if you could explain the problem and
how the patch tries to solve it, we will consider to add code that
solves the problem. But surely not this code. I understand that it is
meant to be a generic solution suitable for all apps. But I am
confident that the same change can be written in half the number of
lines if glib is used for it and I would prefer a small change over a
generic one.

I also very much dislike the fact that this is completely Linux
specific and I would like you to explain the Makefile changes that
would be necessary to get away without the LD_LIBRARY_PATH hack.


Sven

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux