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/cm...@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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers