Am 10.05.2012 23:22, schrieb David Faure: > On Thursday 10 May 2012 12:09:59 Patrick Spendrin wrote: >> Am 10.05.2012 11:52, schrieb David Faure: >>> Even on Windows I like to have everything in one place, but yes, it >>> requires setting PATH. No big deal, though... We're talking about >>> programs run by developers, who have to set PATH anyway (to point to Qt >>> among other things). >> >> No, the problem is different: this is not about setting the path to Qt >> or other installed libraries, but instead to set the path to uninstalled >> libraries: > > I'm also talking about uninstalled libraries. Configure Qt with -prefix=%CD% - > developer-mode to see what I mean: the auto tests for Qt have to find the Qt > libraries. > >> Think of a layout like this >> / >> /src >> /src/first.dll >> /src/tests/firsttest.exe >> >> This would require setting the path to /src and all other such library >> directories where libraries exist that are linked to firsttest.exe. > > Yes. This has ALWAYS been the case for unittests in kdelibs 4. > > Do we generate .bat files that set the PATH, on Windows? > >>>> One other solution I could think of is to link the test executables into >>>> that directory (so that ./kurltest works for you), but I am not sure how >>>> hard that would be. >>> >>> Aeh? You lost me. Linking (creating) the test executables into the current >>> directory, is exactly what this whole discussion is about... >> >> no, making softlinks (ln -s) inside the tests directory. > > Ah! That would work. But it would only solve "finding the binary", not > "finding > the uninstalled libraries" [which is not what this thread was initially > about, > but we're talking about this now]. So while this would be better than > nothing, > we also need an RPATH or wrapper script solution so that "make test" works > (i.e. uses uninstalled libs). > >>> And the solution will exist everywhere: exporting PATH (Windows) or >>> LD_LIBRARY_PATH (Unixes). >> >> One of the problems of PATH is that it is size-restricted: max. 2047 >> chars (think of 20 library destinations à 100 chars) according to >> http://support.microsoft.com/kb/830473 (it could actually also be the >> mentioned 8k chars, but this is probably dependent on Windows version). >> My default environment script already sets PATH to a length of 1400 chars... >> >> If you ensure that there are no more than a handful of library >> destinations, this might of course be ok. > > All libs go into lib/, so in a given module/framework there's only one more > path to add.
Hm, I think I misunderstood something in the beginning. There actually still is a difference between CMAKE_RUNTIME_OUTPUT_DIRECTORY and EXECUTABLE_OUTPUT_PATH - according to the documentation of cmake, CMAKE_RUNTIME_OUTPUT_DIRECTORY supercedes EXECUTABLE_OUTPUT_PATH which leads to the following problematic layouts: if we do not set RUNTIME_OUTPUT_DIRECTORY but only EXECUTABLE_OUTPUT_PATH, libraries will end up whereever they come from on windows which requires additional path calculations etc. if we do set RUNTIME_OUTPUT_DIRECTORY, we move all libraries & executables into one dir on Windows, and on linux we do keep all the libraries where they are (or set LIBRARY_OUTPUT_DIRECTORY) but we still just put all executables into one directory. I have no idea about the rpath stuff, but iirc there was some resetting of rpath going on when running make install to fix the different needs? regards, Patrick _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
