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
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
