cmake news: RPATH, kdevelop projects, finding kdelibs

[Alexander Neundorf]

Hi,

On Monday 20 March 2006 10:43, Thiago Macieira wrote:
> Alexander Neundorf wrote:
> >On Friday 17 March 2006 10:05, Thiago Macieira wrote:
> >> Alexander Neundorf wrote:
> >> >"install" - (not on OS X)
> >> >Compile with RPATH set to the installation directory, the kde library
> >> >directory and the Qt library directory.
> >> >To run the executables during the build, simple wrapper shell scripts
> >> > are created which set (DY)LD_LIBRARY_PATH accordingly.
> >>
> >> Do you pass the -Wl,--enable-new-dtags linker option to g++ during
> >> linking? If you don't, you know by now that setting LD_LIBRARY_PATH
> >> has no effect if you used RPATH, on most distros anyways.
> >>
> >> Anyways, why isn't this option the default and why can't OS X deal
> >> with it?
> >
> >Because AFAIK under OS X  RPATH does not exist, but instead
> > install_name. I guess for OS X the now-defautl behaviour is just right
> > (supposed I did it correctly, which is probably not the case since I
> > cannot test it)
>
> But if the end behaviour is the same (i.e., the final binaries load only
> libraries installed in the destination path), it should be the same
> option.
>
> And I strongly urge to make this option the default. It has to be so for
> released code anyways, or the "no rpath" option. 
> Relinking during installing and leaving clutter in the form of build-paths
> are not options for release code.

Which clutter do you mean ? I'm not aware of any.
The current default option is the one which works best (as in "I don't know of 
any problems with it") , but takes more time when doing "make install". 

I'm no expert in OS X stuff, but if I understood things correctly, this 
linking again when installing isn't necessary on OS X, because the same 
effect is achieved by running "install_name_tool". This AFAIK is much faster 
than linking again, so IMO it's the best solution for OS X.
So these two options are equivalent and I'm not aware of any problems, except 
that installing takes longer on Linux/*BSD.

Disadvantages of the other options:
"none" and "install": in order to run the applications from the build tree, 
wrapper shell scripts have to be invoked. Not dramatic, it works, but running 
the executable directly is nicer.
"both": executables can be run from the build tree directly, but when 
installed, they will still prefer the not-installed libraries over the 
installed libraries. I think this is an option which may be useful for 
developers, who also install the stuff they work on from time to time and 
don't want to wait for the relatively slow "default" make install.

After all, let's just work a bit with the options as they are now, then we'll 
see better what we really need. 
The four options available now should be enough to satisfy most developers 
needs.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net