Re: [ft-devel] FreeType patch (SYSROOT)

[mpsuzuki]

Hi,

I propose to switch the handling of "-rpath" in freetype-config
during the configuration.  For the compatibility with the last
release, it is expected to be disabled by default, and possible
to enable it with some option to the configure.  Also it is
possible to guess if the installation destination includes a set
of libraries with hardwired runtime path and synchronize with them.

The background of my proposal is following (sorry for long text!)

----

I guess the motivation introducing "-rpath" to freetype-config
was something like a situation that multiple freetype runtimes
are stored (released and beta, legacy and latest, vanilla and
patched, etc etc) and a developer wants to specify a version of
the runtimes explicitly, by giving its location path.

And, I guess the motivation introducing "SYSROOT" would be mainly
from cross development.  Recent cross development environments
are often structured as if their header files and libraries are
usable under chroot or NFS-root environments.  The hardwiring of
the library location with the pathname in hosting environment
is not expected behaviour, so, Marc's comment (if "-rpath" will
be restored, its value should not be prefixed by ${SYSROOT}) is
reasonable from such users.

And, I guess the reason why nobody complained about the loss
of "-rpath" since 2009 as following.  When a developer builds
all required binaries by oneself, hardwiring of the right place
of the libraries by "-rpath" would be very useful to skip the
long maintenance of LD_LIBRARY_PATH.  However, the number of
the libraries required by recent applications is becoming
larger and larger, compiling everything by onself would be
far troublesome than 10 years ago.  Using precompiled binaries
and setting long LD_LIBRARY_PATH could be an attractive counter
against the maintenance of the homebrew libraries with "-rpath".

--

I think the expected behaviour of the typical "-rpath" users
and that of the typical "SYSROOT" users would be conflicting.  
But it is possible to assume a situation that SYSROOT-prefixed
-rpath value should be hardwired; think about the situation
a developer is trying to cross-build a set of the libraries
to installed to irregular locations in the target system.

The problem is that how freetype-config can distinguish the
developer who wants to hardwire the library location explicitly,
and who doesn't want to.  In addition, the developer should
be able to guess how freetype-config sets "-rpath", because
freetype is very fundamental library. Unexpected insertion, or,
wrong pathname of the hardwiring will cause many troubles.
The impact would be more harmful than 10 years ago.

Among the developers using "-rpath", I guess, the runtime
rearrangement of the value (aslike SYSROOT environment
variable changes the --includes, --libs output) would be
looking like a "new" convention.  Considering that the
motivation to hardwire the library location is to shortcut
the maintenance of long LD_LIBRARY_PATH, fixing "-rpath"
option behaviour during the configuration process would be
intuitive.

Regards,
mpsuzuki

On Sun, 03 Feb 2013 17:41:09 +0100 (CET)
Werner LEMBERG <address@hidden> wrote:

>
>>> Right now I've discovered that this patch removes the use of the
>>> `$rpath' variable in the `--libs' option of freetype-config (it
>>> seems that I've missed this while writing the ChangeLog entry
>>> then).  Was this intentional?
>>
>> I don't remember exactly. How did you stumble over this now?
>
>I want to generate the freetype-config file at compile time instead of
>configure time, and this is suprisingly tricky (probably due to a
>libtool bug), see
>
>  http://lists.gnu.org/archive/html/libtool/2013-02/msg00001.html
>
>> If you want to add it back, it should be the path to without the
>> SYSROOT.
>
>I would be happy to avoid it...
>
>> There's no need for manual rpath handling if you use autotools
>> (autoconf+automake and probably libtools) as your build system.
>
>Well, almost ten years ago, we *already* used autoconf + automake, and
>there was still a request to use an `-R' option for freetype-config
>output.
>
>> From my point of view it's best to use pkg-config and get rid of the
>> *-config scripts.
>
>I'm quite sure that a lot of people think differently.  The biggest
>problem is that pkg-config is a separate package.
>
>However, we provide support for both.
>
>
>    Werner
>
>_______________________________________________
>Freetype-devel mailing list
>address@hidden
>https://lists.nongnu.org/mailman/listinfo/freetype-devel