setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

[Alexander Neundorf]

On Thursday 10 May 2012, Patrick Spendrin wrote:
> 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.

Yes. I think for Windows this is not even a question, we have to generate them 
into the same directory if it doesn't work otherwise.
I mean, everything would would mean from my POV to break it on purpose for 
Windows.
I just wanted to have the confirmation that this is indeed the case.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120510/cfcfe76b/attachment.html>