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

[Michael Hertling]

On 01/21/2011 08:47 AM, Andreas Pakulat wrote:
> On 21.01.11 01:37:41, Michael Hertling wrote:
>> 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?
> 
> Check the bugreport I mentioned further up in the thread. The docs have
> been expanded to mention this problem with LOCATION and
> RUNTIME_OUTPUT_DIRECTORY. As far as I understood Brad in the report its
> unique to those properties defining where a target ends up on disk (and
> how). And indeed (as he said also) changing the output directory _after_
> querying it (via LOCATION) hints towards a bug in your cmake code, after
> all whatever you did with LOCATION is void if you change the output
> directory again and you'd have to re-run that code.

Thanks for this hint, Andreas; I really should have taken a look at the
bug tracker the day after you filed the report. ;) After one-and-a-half
thought about that issue, it is rather obvious that changing a target's
location on disk after querying the location results in strange effects
one way or another. So, with the improved documentation and the already
obsolete LOCATION property, it's certainly alright now.

Regards,

Michael