Re: [PATCH 3/5] cmake.bbclass: append includedir to implicit include dirs

[Douglas Royds <douglas.royds@taitradio.com>]

An error in my analysis below: We *do* delete the dependency files in 
the in-tree build case as well. The side-effect is masked in both 
in-tree and out-of-tree build cases except here at Tait, where we don't 
delete the entire build at configure time, due to a 20min+ rebuild time, 
even with the benefit of icecc.

The rest of my concern still applies: This setting has no effect in the 
target case, and only an unfortunate side effect in the -native case. 
I'm not clear what the benefit is.


On 11/07/19 2:51 PM, Douglas Royds wrote:

> This commit is having an unintended side-effect in the -native (and 
> probably nativesdk) case.
>
> In the target build, $includedir is normally /usr/include, 
> fully-qualified. This path is already in CMake's list of implicit 
> include directories, and we don't include any header files from the 
> build PC's /usr/include in a target build in any case. This addition 
> to CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES has no effect.
>
> In the -native case, the $includedir is set to STAGING_INCDIR_NATIVE, 
> but this path has already been added to the BUILD_CPPFLAGS as a system 
> include directory, so there will already be no warnings for any header 
> file in the STAGING_INCDIR_NATIVE.
>
> There is a nasty side-effect in the -native case: CMake excludes 
> headers in the CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES from its 
> generated dependency files, meaning that a change in any library 
> header file will not trigger a recompile of affected source files in 
> the dependent CMake component. In out-of-tree builds this isn't a 
> problem, as cmake.bbclass deletes the *entire* ${B} directory at 
> configure time, but where this is not the case, the build breaks with 
> any change in library headers.
>
> I haven't examined the nativesdk case. The $includedir is set off to 
> $SDKPATHNATIVE/usr/include, but this path is not added as a system 
> include dir. The same problem will apply as in the -native case, that 
> CMake will not generate dependencies for headers staged in the 
> SDKPATHNATIVE.
>
> Was nativesdk perhaps the intended case for this commit? Is there a 
> better way to silence warnings in this case? Do we need to silence 
> library header warnings at all? Should we instead add 
> $SDKPATHNATIVE/usr/include as a system include dir via the 
> BUILDSDK_CPPFLAGS?
>
> I examined this problem using the Unix Makefiles generator. CMake 
> appears to equally exclude these headers from the ninja *.o.d 
> dependency files, though I haven't examined it closely.
>
>
> On 30/11/18 1:21 AM, Mikko Rapeli wrote:
>
>> From: Michael Ho <Michael.Ho@bmw.de>
>>
>> This resolves issues with paths being marked as system includes that
>> differ from /usr/include but are considered implicit by the toolchain.
>> This enables developers to add directories to system includes
>> to supress compiler compiler warnings from them.
>>
>> Signed-off-by: Michael Ho <Michael.Ho@bmw.de>
>> Cc: Pascal Bach <pascal.bach@siemens.com>
>> ---
>>   meta/classes/cmake.bbclass | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
>> index fd40a98..485aea6 100644
>> --- a/meta/classes/cmake.bbclass
>> +++ b/meta/classes/cmake.bbclass
>> @@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH 
>> "${STAGING_DATADIR}/cmake/Modules/")
>>   # add for non /usr/lib libdir, e.g. /usr/lib64
>>   set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
>>   +# add include dir to implicit includes in case it differs from 
>> /usr/include
>> +list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
>> +list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
>> +
>>   EOF
>>   }
>
>