Revision: 77483
http://sourceforge.net/p/brlcad/code/77483
Author: starseeker
Date: 2020-10-18 15:47:10 +0000 (Sun, 18 Oct 2020)
Log Message:
-----------
No wonder the ninja multiconfig builds seemed fast in Release - we're not
propagating the build flags for multiconfig setups, and for the first time
that's now a real issue. May explain why the step-g fails in multiconfig
release and works in single config release with Ninja, but regardless we'll
have to sort this out before we can compare apples to apples even if that's not
the problem...
Modified Paths:
--------------
brlcad/branches/thirdparty_rework/CMakeLists.txt
Modified: brlcad/branches/thirdparty_rework/CMakeLists.txt
===================================================================
--- brlcad/branches/thirdparty_rework/CMakeLists.txt 2020-10-18 15:19:10 UTC
(rev 77482)
+++ brlcad/branches/thirdparty_rework/CMakeLists.txt 2020-10-18 15:47:10 UTC
(rev 77483)
@@ -540,6 +540,15 @@
message("***********************************************************")
endif(BRLCAD_PRINT_MSGS)
+# TODO: GAH! Our compiler flag management has always been centered on single
+# configuration builds, so we've never actually properly set up to manage the
+# population of CMAKE_C_FLAGS_DEBUG, CMAKE_C_FLAGS_RELEASE, etc. We don't
+# manage build flags much with MSVC, so up until recently Xcode would have been
+# the only practical scenario where this would have been an issue and Xcode is
+# not extensively used/tested with BRL-CAD. However, with the new Ninja
+# Multi-Config CMake generator, we can't assume single-config any more for
+# build flags, which implies a re-think on how we are tracking this.
+
# load our compiler testing macro definitions
include(CompilerFlags)
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
