[cmake-developers] Ninja generator and __FILE__ (was: Ninja: Fix failing CMakeLib.testRST test)

[Sam Spilsbury]

On Fri, Jun 6, 2014 at 11:05 PM, Brad King <brad.king at kitware.com> wrote:
> On 06/06/2014 10:53 AM, Sam Spilsbury wrote:
>> On Fri, Jun 6, 2014 at 10:49 PM, Brad King <brad.king at kitware.com> wrote:
>>> On 06/06/2014 10:12 AM, Sam Spilsbury wrote:
>>>> For the sake of consistency, an absolute path should always be passed
>>>> to the compiler on each generator, so that __FILE__ is always
>>>> consistent.
>>>
>>> This is a larger debate for those that develop and use the Ninja
>>> generator.
>>
>> Are there any threads where I can read up on background information
>> for this? Having consistency seems like a no-brainer to me, so perhaps
>> I missed something?
>>
>> Briefly reading[1], it seems like the Chromium developers are
>> preferring consistency between generator backends.
>>
>> [1] https://code.google.com/p/chromium/issues/detail?id=326030
>
> This appears to be a result of using
>
>   command = ... -c $in
>
> as the compilation rule so that the dependency path and the path given
> to the compiler on the command line are the same.  In order to always
> pass a full path to the compiler then either ninja would have to do
> it when constructing the command or the generated rule would have to
> separately pass in the path to the source.  I'm not familiar enough
> with the ninja tool or the CMake Ninja generator to say more.
>
> -Brad

Thanks for the pointers,

It seems like the problem is that the dependency path can't be an
absolute path, but the path passed to the compiler can be.

Is there any problem with the dependency path being an absolute path?
I suppose the trade-off is that you lose source-and-build-directory
relocatability, but both the Makefile and Ninja generators don't
appear to support that anyways (e.g., CMake is re-run on the old path
to the source directory, which fails).

Sam.


-- 
Sam Spilsbury