Am 10.05.2012 11:52, schrieb David Faure:
> On Thursday 10 May 2012 11:15:57 Patrick Spendrin wrote:
>> Am 10.05.2012 10:45, schrieb David Faure:
>>> On Thursday 10 May 2012 10:36:20 Patrick Spendrin wrote:
>>>>> set(EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
>>>>
>>>> Yes, the EXECUTABLE_OUTPUT_PATH should be set per project into the
>>>> project binary_dir\bin
>>>
>>> As a linux developer, I don't like this. I want to be able to do
>>> make && ./kurltest
>>> or make kurltest/fast && ./kurltest
>>> rather than
>>> make && ../../bin/kurltest
>>
>> Well, I don't want to impose this on Linux, I would even think
>> restricting this to windows is ok.
>
> 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:
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.
>
>> 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.
>
>>> And why is it OK for Qt autotests (to be built in the directory containing
>>> the sources), but not for kde frameworks autotests?
>>
>> The problem will exist everywhere, except if tests are statically linked
>> to the tested code.
>
> 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.
regards,
Patrick
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
