[cmake-developers] Modifying RPATH feature to run tests uninstalled

Alexander Neundorf neundorf at kde.org
Fri Feb 17 02:51:19 EST 2012


On Friday 17 February 2012, Stephen Kelly wrote:
> Hi there,
> 
> One of the macros we have in KDE creates shell scripts to initialize
> environment variables needed on various platforms so that tests can be run
> before installation. If RPATH is enabled, the scripts are not needed, but
> RPATH is sometimes disabled, so the scripts are the solution to that.
> 
> With the modularization of kdelibs into KDE frameworks (multiple
> independent pieces), we wondered what to do with that macro and how we can
> retain its features easily after making kdelibs non-monolithic.
> 
> I chatted with debian packager Sune Vuorela this evening about this. The
> linked thread is long and contains long emails, so all of the context is in
> the IRC log.
> 
> <steveire> svuorela: ping?
> <steveire> I'm wondering about debian packages.
> <steveire> Is it normal to run tests before installing them?
> <steveire> Grep for 'Sune' here:
> http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=201
> <svuorela> steveire: it depends on the package. we aren't running kdelibs
> tests, but we are running libc tests
> <steveire> svuorela: And do you run them before installation?
> <svuorela> steveire: I think so yes. but even if run after installation it
> is in a weird prefix (DESTDIR)
> <steveire> By coincidence I got an email yesterday from bricks (who
> packages Grantlee) and he was asking about running tests before
> installation. He hit the issue in that thread for the exact reason that is
> there (ie debian disabled RPATH). Is that the 'normal' way to run tests in
> debian packaging systems?
> <svuorela> steveire: so even if RPATH was set you coulddn't easily actually
> find the installed bits ...
> <steveire> ... if the install location isn't already in LD_LIBRARY_PATH?
> <svuorela> ...but as a normal user, I would expect that make intsall is
> something I run after a succsessfull make test
> <steveire> svuorela: What do you think of Alex' suggestion? Or should
> CMAKE_SKIP_RPATH only disable the RPATH for the install tree ?
> <steveire> Debian packagers still wouldn't allow the RPATH to be used in
> the binary dir, would they?
> <steveire> So it still wouldn't be possbile to run them uninstalled?
> <svuorela> at least from a debian pov, it is the installed version of
> things that matters. if  there is a intermediate RPATH at a stage during
> compilation no one would care.
> <svuorela> and I actually think that it makes quite good sense to have
> RPATH on during compilation
> <steveire> Right, which is why kde creates wrapper scripts to run unit
> tests with env vars set to find the libraries.
> <steveire> It looks like this is the most likely solution: http://www.mail-
> archive.com/cmake at cmake.org/msg12056.html What do you think?
> <steveire> We could add LD_LIBRARY_PATH/DYLD_LIBRARY_PATH/PATH in a command
> like that.
> <svuorela> steveire: I think it makes good sense both to have RPATHs in the
> build tree (and strip them on install if -DCMAKE_SKIP_RPATH) and to have a
> way of setting env vars for make test
> <steveire> svuorela: Ok, do you mind if I post some of this discussion to
> the cmake-developers list?
> <svuorela> steveire: feel free.
> 
> 
> So the suggestion is
> 
> a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but not when
> building (I don't know if that's easy in CMake), or alternatively provide
> another CMAKE_ variable to do that.
> 
> b) Implement something like:
> set_property(TARGET foo APPEND PROPERTY TEST_ENVIRONMENT "foo=bar")
> 
> 
> Possibly both a) and b).
> 
> Thoughts/comments?

b) is IMO definitely a missing feature.
(but even with that, we (KDE) would have to keep a macro, because we can't 
expect that all developers know how to set this properly for all platforms. 
...or, since it is a target property, this could be also intialized from a 
CMAKE_TEST_ENVIRONMENT cmake variable).

a) To change CMAKE_SKIP_RPATH so that it leaves the RPATH on in the build 
tree, but not in the install tree, IMO makes sense. It's also a good sign that 
Sune, a Debian packager, says it doesn't matter for Debian what happens in the 
build tree, but I don't know whether it would be ok for everybody.


Alex



More information about the cmake-developers mailing list