setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

[Patrick Spendrin]

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