[CMake] Restrictions on where a binary can be put?

[Michael Hertling]

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