On 01/20/2011 07:01 PM, Alexander Neundorf wrote: > On Sunday 09 January 2011, Michael Hertling wrote: >> On 01/09/2011 09:47 PM, Nizar Khalifa Sallem wrote: >>> At Sun, 09 Jan 2011 21:42:49 +0100, >>> >>> Michael Hertling wrote: >>>> On 01/09/2011 09:09 PM, Andreas Pakulat wrote: >>>>> On 09.01.11 21:05:21, Andreas Pakulat wrote: >>>>>> On 09.01.11 14:24:16, Michael Hertling wrote: >>>>>>> On 01/09/2011 12:58 PM, Andreas Pakulat wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm having a bit of a problem here changing the runtime output >>>>>>>> directory for a binary. Its an executable target named 'setup' and >>>>>>>> I'd like to put it into the top-level directory. Unfortunately it >>>>>>>> always ends up in the bin/ directory, which is what >>>>>>>> CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to. >>>>>>>> >>>>>>>> I'm using >>>>>>>> set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY >>>>>>>> ${CMAKE_BINARY_DIR} ) after creating the target currently, which >>>>>>>> should work as far as I can see from the documentation. Are there >>>>>>>> maybe any restrictions on what the directory may be or what targets >>>>>>>> can be put there? >>>>>>>> >>>>>>>> If not, any suggestions how to debug this? I can see that the >>>>>>>> build.make does already have the rule setup for putting the binary >>>>>>>> into bin/, so it must be going wrong somewhere in the generation >>>>>>>> stage, but a simple cmake --trace doesn't show up anything >>>>>>>> suspicious. Is there a switch to follow the steps that cmake does >>>>>>>> during makefile-generation? >>>>>>> >>>>>>> Could you provide a minimal but complete example? >>>>>> >>>>>> Ok, attached case produces the error. Apparently the problem is >>>>>> fetching the LOCATION property from the target and setting the >>>>>> RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so >>>>>> I'll file a report. >>>>> >>>>> Ooops, forgot the attachment :) >>>> >>>> Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the >>>> LOCATION apparently renders the following SET_TARGET_PROPERTY() on the >>>> RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for >>>> this, I'd agree that it should be considered as a bug. Besides, my >>>> example was pointless: A simple clash of an executable "main" with >>>> a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/ >>>> >>>> Regards, >>>> >>>> Michael >>> >>> I don't really understand why you want to get the LOCATION from your >>> target, anyway, the get_target_property works fine if you use >>> set_target_properties before it. [...] >> >> ...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after >> GET_TARGET_PROPERTY(), even if both operate on different properties. > > Well, they are not completely different. > If I remember correctly, the LOCATION property is "calculcated" when you > query > it. I think it changes some internal variables. Apparently to a state where > setting the target property afterwards doesn't have the desired effect > anymore :-/
So, what's your conclusion in this matter? Should the behavior in question be considered as a bug or is it alright? IMO, such a subtle side effect of a read operation on a subsequent write operation is at least highly surprising. Besides, does one have to take this phenomenon into account elsewhere, i.e. when saying GET_TARGET_PROPERTY(<VAR> <TARGET> X) ... SET_TARGET_PROPERTIES(<TARGET> PROPERTIES Y ...) with X!=LOCATION and Y!=RUNTIME_OUTPUT_DIRECTORY, is it assured that the latter command works as expected? Are directory or source files properties possibly affected, too? Regards, Michael _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake