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...@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...@bmw.de>
Cc: Pascal Bach <pascal.b...@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
}
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core