On 1/16/19 7:38 PM, Douglas Royds wrote:
On 17/01/19 12:01 PM, Richard Purdie wrote:

On Thu, 2019-01-17 at 11:51 +1300, Douglas Royds wrote:
From: Sam Nobs <[email protected]>

The do_configure task is sensitive to changes in recipes and
configuration files.
This can be time consuming because cmake.bbclass deletes the ${B}
directory
at the beginning of the do_configure task. CMake figures
out what to do when it's run again, so unless your cmake files are
buggy, there shouldn't
be any need to erase the build directory and start afresh.

This change allows you to turn this behaviour off, either globally or
on a per-recipe basis, e.g.

OECMAKE_CLEAN_BUILDDIR_ON_CONFIGURE_pn-yourrecipe = ""

Signed-off-by: Sam Nobs <[email protected]>
---
  meta/classes/cmake.bbclass | 23 ++++++++++++++++++-----
  1 file changed, 18 insertions(+), 5 deletions(-)
This may give a speed boost for some cases but it does come at a
potential risk of determinism issues.

I appreciate you've made it configurable but that actually further
concerns me as we now have two code paths which potentially both have
to be tested.

Is this change really worth it?

Cheers,

Richard


For us, the benefit is beyond question - on our proprietary C++ component, the compile from scratch after a configure is punishing, 10s of minutes per MACHINE.

We are counting on binary reproducibility to flush out any determinism issues with the CMake code, that is, we will be comparing our incremental builds with our clean builds. Note also that we are deleting all the generated CMake artefacts, but leaving the object files behind. CMake will force a complete rebuild should there be any change in the CFLAGS and friends.

Douglas,

What workflow are you trying to optimize?

If you're strictly changing existing source files
then you shouldn't need to run configure again so I'm confused.

Also, have you tried using ccache as per:
   d014c8c11f cmake.bbclass: Make it work with ccache
and if so why doesn't that work for you?

Thanks,
../Randy



diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fa7f68c99b..b9ec68ac9a 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -63,6 +63,11 @@ EXTRA_OECMAKE_BUILD_prepend_task-install =
"${PARALLEL_MAKEINST}"
  OECMAKE_TARGET_COMPILE ?= "all"
  OECMAKE_TARGET_INSTALL ?= "install"
+# Clean the build directory before configuring.
+# Some recipes don't want/need this as cmake is perfectly
+# capable of figuring out what to do, so we allow it to be turned
off
+OECMAKE_CLEAN_BUILDDIR_ON_CONFIGURE ??= "true"
+
  # CMake expects target architectures in the format of uname(2),
  # which do not always match TARGET_ARCH, so all the necessary
  # conversions should happen here.
@@ -133,12 +138,20 @@ cmake_do_configure() {
          bbnote "cmake.bbclass no longer uses
OECMAKE_BUILDPATH.  The default behaviour is now out-of-tree builds
with B=WORKDIR/build."
      fi
-    if [ "${S}" != "${B}" ]; then
-        rm -rf ${B}
-        mkdir -p ${B}
-        cd ${B}
+    if [ ${@oe.types.boolean('${OECMAKE_CLEAN_BUILDDIR_ON_CONFIGURE
}')} = True ]; then
+        if [ "${S}" != "${B}" ]; then
+            rm -rf ${B}
+            mkdir -p ${B}
+            cd ${B}
+        else
+            # For an in-tree build, delete all object files
and CMake artefacts
+            find ${B} -name CMakeFiles -or -name Makefile
-or -name cmake_install.cmake -or -name CMakeCache.txt -delete
+        fi
      else
-        find ${B} -name CMakeFiles -or -name Makefile -or -name
cmake_install.cmake -or -name CMakeCache.txt -delete
+        # Selectively delete CMake artefacts to ensure that -c
configure has a consistent result
+        rm -f CMakeCache.txt
+        cmake_version=$(cmake --version | head -1 | sed
's#^[^0-9]*\([0-9.]*\).*$#\1#' )
+        rm -fr CMakeFiles/$cmake_version/
      fi
      # Just like autotools cmake can use a site file to cache result
that need generated binaries to run
--
2.17.1




--
# Randy MacLeod
# Wind River Linux
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to