Re: [cmake-developers] CMake and intersphinx
On 03/22/2015 07:16 AM, Gregor Jasny wrote: On 21/03/15 12:06, Alex Merry wrote: On Saturday 21 March 2015 09:41:06 Gregor Jasny wrote: I wanted to start documenting our in-company CMake modules. Often I'd like to refer to some basic CMake commands. As far as I understand the intersphinx extension [1] should be able to provide that. To reference remote projects these need to provide a objects.inv mapping file. This would also be useful for the extra-cmake-modules project. I pushed a topic branch to stage and await ACK for merging to next: http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=840f5b89a456b6f68a9b75c7a0a0bfc3fa37e643 Thanks. Yes, please merge that to 'next'. FYI, we do publish that file with the online documentation: http://www.cmake.org/cmake/help/v3.2/objects.inv http://www.cmake.org/cmake/help/v3.1/objects.inv http://www.cmake.org/cmake/help/v3.0/objects.inv so other documentation can cross-reference to docs at those URLs. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015468]: Generated Xcode project contains source groups for ALL_BUILD and ZERO_CHECK targets
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15468 == Reported By:Abigail Bunyan Assigned To: == Project:CMake Issue ID: 15468 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-23 11:28 EDT Last Modified: 2015-03-23 11:28 EDT == Summary:Generated Xcode project contains source groups for ALL_BUILD and ZERO_CHECK targets Description: When using the Xcode generator, each file in a target is placed under a target-specific source group. (If a file has a custom source group specified, then that group will be created as a subgroup of the target's.) However, ALL_BUILD and ZERO_CHECK also generate their own source groups. This is not intended behavior: cmGlobalXCodeGenerator::CreateGroups (at cmGlobalXCodeGenerator.cxx:3018) has a comment specifying that these should be skipped, and code that is supposed to skip them. These erroneous source groups contain CMakeLists.txt, and an empty subgroup called CMake Rules. == Issue History Date ModifiedUsername FieldChange == 2015-03-23 11:28 Abigail Bunyan New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler
On Mar 20 [13:08], Brad King wrote:
On 03/20/2015 04:23 AM, Steven Vancoillie wrote:
Looking at other compiler configurations, it seems it might be better
to have a SunPro.cmake module that combines flags that are independent
of the language?
Yes. This refactoring has simply not been done for this compiler.
If you want to work on it, please note that such a module is not
loaded automatically and must be included by the per-language
modules. This pattern is visible in several other compiler modules.
I've included a candidate patch for this refactoring.
I also noticed the follow variables are set for C, CSS, and ASM:
set(CMAKE_${type}_LINK_STATIC_${lang}_FLAGS -Bstatic)
set(CMAKE_${type}_LINK_DYNAMIC_${lang}_FLAGS -Bdynamic)
I could add these for Fortran as well and move it also to the
macro in SunPro.cmake. However, since this only seems to be there
for SunPro, I wondered if these are used at all? These options are
just passed to ld, so they are not sun-specific.
grtz
Steven
From b541e110cdc3404ac7b5ac0c24f501c2216058bb Mon Sep 17 00:00:00 2001
From: Steven Vancoillie steven.vancoil...@teokem.lu.se
Date: Mon, 23 Mar 2015 09:22:14 +0100
Subject: [PATCH] Combine SunPro compiler flags for multiple languages
Merge equivalent compiler flags into one single SunPro.cmake file,
which are then imported into the per-language modules.
This also removes the non-existent -KPIE option.
---
Modules/Compiler/SunPro-ASM.cmake | 17 +++---
Modules/Compiler/SunPro-C.cmake | 20 ++---
Modules/Compiler/SunPro-CXX.cmake | 21 ++
Modules/Compiler/SunPro-Fortran.cmake | 17 +++---
Modules/Compiler/SunPro.cmake | 42 +++
5 files changed, 52 insertions(+), 65 deletions(-)
create mode 100644 Modules/Compiler/SunPro.cmake
diff --git a/Modules/Compiler/SunPro-ASM.cmake b/Modules/Compiler/SunPro-ASM.cmake
index 2fa8b99..fc17271 100644
--- a/Modules/Compiler/SunPro-ASM.cmake
+++ b/Modules/Compiler/SunPro-ASM.cmake
@@ -1,18 +1,7 @@
-set(CMAKE_ASM_SOURCE_FILE_EXTENSIONS s )
-
-set(CMAKE_ASM_VERBOSE_FLAG -#)
+include(Compiler/SunPro)
+__compiler_sunpro(ASM)
-set(CMAKE_SHARED_LIBRARY_ASM_FLAGS -KPIC)
-set(CMAKE_SHARED_LIBRARY_CREATE_ASM_FLAGS -G)
-set(CMAKE_SHARED_LIBRARY_RUNTIME_ASM_FLAG -R)
-set(CMAKE_SHARED_LIBRARY_RUNTIME_ASM_FLAG_SEP :)
-set(CMAKE_SHARED_LIBRARY_SONAME_ASM_FLAG -h)
-
-set(CMAKE_ASM_FLAGS_INIT )
-set(CMAKE_ASM_FLAGS_DEBUG_INIT -g)
-set(CMAKE_ASM_FLAGS_MINSIZEREL_INIT -xO2 -xspace -DNDEBUG)
-set(CMAKE_ASM_FLAGS_RELEASE_INIT -xO3 -DNDEBUG)
-set(CMAKE_ASM_FLAGS_RELWITHDEBINFO_INIT -g -xO2 -DNDEBUG)
+set(CMAKE_ASM_SOURCE_FILE_EXTENSIONS s )
# Initialize ASM link type selection flags. These flags are used when
# building a shared library, shared module, or executable that links
diff --git a/Modules/Compiler/SunPro-C.cmake b/Modules/Compiler/SunPro-C.cmake
index c5b5203..a065d75 100644
--- a/Modules/Compiler/SunPro-C.cmake
+++ b/Modules/Compiler/SunPro-C.cmake
@@ -1,18 +1,5 @@
-set(CMAKE_C_VERBOSE_FLAG -#)
-
-set(CMAKE_C_COMPILE_OPTIONS_PIC -KPIC)
-set(CMAKE_C_COMPILE_OPTIONS_PIE -KPIE)
-set(CMAKE_SHARED_LIBRARY_C_FLAGS -KPIC)
-set(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS -G)
-set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG -R)
-set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG_SEP :)
-set(CMAKE_SHARED_LIBRARY_SONAME_C_FLAG -h)
-
-set(CMAKE_C_FLAGS_INIT )
-set(CMAKE_C_FLAGS_DEBUG_INIT -g)
-set(CMAKE_C_FLAGS_MINSIZEREL_INIT -xO2 -xspace -DNDEBUG)
-set(CMAKE_C_FLAGS_RELEASE_INIT -xO3 -DNDEBUG)
-set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT -g -xO2 -DNDEBUG)
+include(Compiler/SunPro)
+__compiler_sunpro(C)
# Initialize C link type selection flags. These flags are used when
# building a shared library, shared module, or executable that links
@@ -22,6 +9,3 @@ foreach(type SHARED_LIBRARY SHARED_MODULE EXE)
set(CMAKE_${type}_LINK_STATIC_C_FLAGS -Bstatic)
set(CMAKE_${type}_LINK_DYNAMIC_C_FLAGS -Bdynamic)
endforeach()
-
-set(CMAKE_C_CREATE_PREPROCESSED_SOURCE CMAKE_C_COMPILER DEFINES FLAGS -E SOURCE PREPROCESSED_SOURCE)
-set(CMAKE_C_CREATE_ASSEMBLY_SOURCE CMAKE_C_COMPILER DEFINES FLAGS -S SOURCE -o ASSEMBLY_SOURCE)
diff --git a/Modules/Compiler/SunPro-CXX.cmake b/Modules/Compiler/SunPro-CXX.cmake
index c7bc734..fee75f3 100644
--- a/Modules/Compiler/SunPro-CXX.cmake
+++ b/Modules/Compiler/SunPro-CXX.cmake
@@ -1,19 +1,5 @@
-set(CMAKE_CXX_VERBOSE_FLAG -v)
-
-set(CMAKE_CXX_COMPILE_OPTIONS_PIC -KPIC)
-set(CMAKE_CXX_COMPILE_OPTIONS_PIE -KPIE)
-set(CMAKE_SHARED_LIBRARY_CXX_FLAGS -KPIC)
-set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS -G)
-set(CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG -R)
-set(CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG_SEP :)
-set(CMAKE_SHARED_LIBRARY_SONAME_CXX_FLAG -h)
-
-set(CMAKE_CXX_FLAGS_INIT )
-set(CMAKE_CXX_FLAGS_DEBUG_INIT -g)
-set(CMAKE_CXX_FLAGS_MINSIZEREL_INIT -xO2 -xspace -DNDEBUG)
-set(CMAKE_CXX_FLAGS_RELEASE_INIT -xO3 -DNDEBUG)
-set(CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT -g -xO2 -DNDEBUG)
-
+include(Compiler/SunPro)
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
On 03/19/2015 09:57 AM, Geoffrey Viola wrote: I moved it under #if defined(_WIN32) !defined(__CYGWIN__) # if !defined(CMAKE_BOOT_MINGW) The #include line needs to be moved similarly. I made that fix and a few whitespace fixes. I've attached a patch with those revisions. I noticed while making those fixes that you're using auto_ptr inside a map value. The auto_ptr is documented as not suitable for use in containers in general. For TargetFolderBuildStreams you could just use a normal pointer and then cleanup in the generator destructor using cmDeleteAll. Thanks, -Brad From 9ef934f7b3abcd8560197fa16ad6b06eb5708d3b Mon Sep 17 00:00:00 2001 Message-Id: 9ef934f7b3abcd8560197fa16ad6b06eb5708d3b.1427119119.git.brad.k...@kitware.com From: Geoff Viola geoffrey.vi...@autonomoussolutions.com Date: Mon, 26 Jan 2015 21:38:27 -0700 Subject: [PATCH] Added-some-support-for-a-Green-Hills-MULTI --- Help/generator/Green Hills MULTI.rst | 11 + Help/manual/cmake-generators.7.rst | 1 + Help/manual/cmake-variables.7.rst| 1 + Help/variable/CMAKE_MAKE_PROGRAM.rst | 2 + Help/variable/CMAKE_SYSTEM_PROCESSOR.rst | 2 + Help/variable/GHS-MULTI.rst | 4 + Modules/Compiler/GHS-DetermineCompiler.cmake | 6 + Modules/FindBoost.cmake | 5 +- Modules/Platform/GHS-MULTI-Initialize.cmake | 29 ++ Modules/Platform/GHS-MULTI.cmake | 27 ++ Source/CMakeLists.txt| 9 + Source/cmGhsMultiGpj.cxx | 39 +++ Source/cmGhsMultiGpj.h | 31 ++ Source/cmGhsMultiTargetGenerator.cxx | 431 ++ Source/cmGhsMultiTargetGenerator.h | 92 ++ Source/cmGlobalGhsMultiGenerator.cxx | 443 +++ Source/cmGlobalGhsMultiGenerator.h | 127 Source/cmGlobalNinjaGenerator.cxx| 1 + Source/cmLocalGhsMultiGenerator.cxx | 48 +++ Source/cmLocalGhsMultiGenerator.h| 54 Source/cmake.cxx | 3 + Tests/CMakeLists.txt | 17 + Tests/GhsMulti/CMakeLists.txt| 4 + Tests/GhsMulti/ReturnNum/App/CMakeLists.txt | 4 + Tests/GhsMulti/ReturnNum/App/Main.c | 8 + Tests/GhsMulti/ReturnNum/CMakeLists.txt | 3 + Tests/GhsMulti/ReturnNum/Int/AppDD.int | 12 + Tests/GhsMulti/ReturnNum/Int/CMakeLists.txt | 1 + Tests/GhsMulti/ReturnNum/Int/Default.bsp | 35 +++ Tests/GhsMulti/ReturnNum/Lib/CMakeLists.txt | 1 + Tests/GhsMulti/ReturnNum/Lib/HelperFun.c | 4 + Tests/GhsMulti/ReturnNum/Lib/HelperFun.h | 1 + 32 files changed, 1455 insertions(+), 1 deletion(-) create mode 100644 Help/generator/Green Hills MULTI.rst create mode 100644 Help/variable/GHS-MULTI.rst create mode 100644 Modules/Compiler/GHS-DetermineCompiler.cmake create mode 100644 Modules/Platform/GHS-MULTI-Initialize.cmake create mode 100644 Modules/Platform/GHS-MULTI.cmake create mode 100644 Source/cmGhsMultiGpj.cxx create mode 100644 Source/cmGhsMultiGpj.h create mode 100644 Source/cmGhsMultiTargetGenerator.cxx create mode 100644 Source/cmGhsMultiTargetGenerator.h create mode 100644 Source/cmGlobalGhsMultiGenerator.cxx create mode 100644 Source/cmGlobalGhsMultiGenerator.h create mode 100644 Source/cmLocalGhsMultiGenerator.cxx create mode 100644 Source/cmLocalGhsMultiGenerator.h create mode 100644 Tests/GhsMulti/CMakeLists.txt create mode 100644 Tests/GhsMulti/ReturnNum/App/CMakeLists.txt create mode 100644 Tests/GhsMulti/ReturnNum/App/Main.c create mode 100644 Tests/GhsMulti/ReturnNum/CMakeLists.txt create mode 100644 Tests/GhsMulti/ReturnNum/Int/AppDD.int create mode 100644 Tests/GhsMulti/ReturnNum/Int/CMakeLists.txt create mode 100644 Tests/GhsMulti/ReturnNum/Int/Default.bsp create mode 100644 Tests/GhsMulti/ReturnNum/Lib/CMakeLists.txt create mode 100644 Tests/GhsMulti/ReturnNum/Lib/HelperFun.c create mode 100644 Tests/GhsMulti/ReturnNum/Lib/HelperFun.h diff --git a/Help/generator/Green Hills MULTI.rst b/Help/generator/Green Hills MULTI.rst new file mode 100644 index 000..79695f1 --- /dev/null +++ b/Help/generator/Green Hills MULTI.rst @@ -0,0 +1,11 @@ +Green Hills MULTI +- + +Generates Green Hills MULTI project files. + +Customizations are available through the following cache variables: + +* ``GHS_BSP_NAME`` +* ``GHS_CUSTOMIZATION`` +* ``GHS_GPJ_MACROS`` +* ``GHS_OS_DIR`` diff --git a/Help/manual/cmake-generators.7.rst b/Help/manual/cmake-generators.7.rst index 804229b..ce9f5c8 100644 --- a/Help/manual/cmake-generators.7.rst +++ b/Help/manual/cmake-generators.7.rst @@ -56,6 +56,7 @@ one may launch CMake from any environment. .. toctree:: :maxdepth: 1 + /generator/Green Hills MULTI /generator/Visual Studio 6 /generator/Visual Studio 7 /generator/Visual Studio 7 .NET 2003 diff --git a/Help/manual/cmake-variables.7.rst
Re: [cmake-developers] Extracting target metadata, IDE integration
On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote: On 15.03.2015 16:42, Tobias Hunger wrote: Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. The build system that CMake generates knows the header dependencies and decides when which files need rebuilding. CMake itself doesn't know. How header dependencies are determined and where and how they are recorded is generator specific. I have spent enough time on this code, so: nitpicking for the makefile-generators, the header dependencies are generated by cmake (not at cmake time, but at build time), which results in the depend.make file. /nitpicking Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] CMake 3.3 feature freeze on 2015-06-01
Hi Folks, The feature freeze in 'master' for CMake 3.3 will be on June 1, 2015. I will announce a freeze in 'next' sometime in the preceding week so that we can get any remaining dashboard trouble cleaned up. Please schedule any planned topics accordingly. Any major or disruptive changes should be completed a few weeks prior to the freeze or delayed until after 'next' re-opens. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] BlueGene/Q Platform files
Hi, Looks good. We have bundled similar content in GROMACS for a while. Can I add one for bgclang? Mark On 23/03/2015 6:21 am, Todd Gamblin tgamb...@llnl.gov wrote: Done! Thanks. On 3/20/15, 7:19 AM, Brad King brad.k...@kitware.com wrote: On 03/19/2015 02:53 AM, Todd Gamblin wrote: Let me know if I can merge this topic to next. Yes, please. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating buildsystem metadata from CMake
Tobias Hunger wrote:
and
which kit (think set of compiler, Qt, some other settings) were used
to in the built in that directory.
Is this hypothetical? Currently I can add a compiler location and a Qt
location in QtCreator, and I can create a kit and give it a name and
partcular compiler and Qt. However, the information I configure there and
the kit that I choose is not passed to cmake when creator invokes that,
right? CMake will do its own determination of the compiler to use, and
will find Qt on its own, right? Unless the user manually sets those as
arguments in the 'Run CMake' dialog page.
We do that for qmake projects at this time.
Nothing listed here is needed to get the level of cmake support we
have in Creator right *now*: That works fine already after all. I want
something better:-) So I bring up all the things I can think of to get
cmake to the same level that we currently have for qmake.
Right, I see.
Or are you thinking of scenarios such as 'the user creates a build
outside of Creator and then tries to open it in creator'. Given that 'a
kit' is something internal to Creator, there is no way CMake could tell
you the kit in that scenario. Is that obvious or am I missing something?
I think the best thing you can do there is find out which compiler was
used, and what the value of Qt5Core_DIR is, and map that to things you
know about available kits to find the match if there is one.
Yes, that is the same we do for qmake projects. In fact we just create
a new kit for configurations we had not seen before.
Right. In the case that Creator imports a cmake build dir for a project
which uses Qt 5, and which is not already configured in Creator, you would
need the path to qmake for the Qt used by it, because that is what Creator
uses as the key for a particular Qt (or that used to be the case).
By the way, just as another tip, in that case the reliable way to get the
corresponding qmake would be to get the Qt5Core_DIR from the cache in the
just-found build dir (via the json or whatever), and write a file to a temp
dir with the content:
cmake_minimum_required(VERSION 2.8)
project(find_qmake NONE)
find_package(Qt5Core REQUIRED)
get_target_property(loc Qt5::qmake LOCATION)
message(QMAKE_LOCATION: \${loc}\)
and then run cmake on it and parse the result:
stephen@hal:/tmp/cmake/build$ cmake .. \
-DQt5Core_DIR=/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/
QMAKE_LOCATION: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/cmake/build
stephen@hal:/tmp/cmake/build$ cmake .. \
-DQt5Core_DIR=/opt/qt/binary/Qt5.2.1/5.2.1/gcc_64/lib/cmake/Qt5Core
QMAKE_LOCATION: /opt/qt/binary/Qt5.2.1/5.2.1/gcc_64/bin/qmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/cmake/build
I only want the IDE to re-generate when I'm actually working in the IDE.
If I edit any file and hit Ctrl+B, the IDE runs 'cmake --build .' and
cmake regenerates if needed at that point. It's 'ok' if the project tree
is technically 'stale' after I edit a file and before I hit Ctrl+B. It's
'ok' in the sense that the alternative is 'worse' as far as my opinion
goes. You also have the option of running 'cmake .' any time any file is
saved in the IDE, if that improves the experience, but I strongly believe
you shouldn't be watching the files for outside changes and re-generating
in response.
That might be ok for you, but we do get a lot of bug reports whenever
we have the project tree not update directly.
'Update directly' means 'I save a file in the IDE and the target treeview
updates', right?
Quoting myself above: running 'cmake .' any time any file is saved in the
IDE.
So it is *not* ok for a
large number of users, particularly those that come from a proprietary
IDE that comes with a built-in build system.
For my curiosity, what scenario are you talking about which is not covered
by triggering regeneration on 'saving in the IDE' and 'newly getting focus'?
We do *not* update creator while it is not in use.
Fantastic!
When the window
gets focus again we go Things have changed outside Creator, do you
want to update?.
Great.
That's not to say we won't 'give you the rope'. But before we would do
that, cmake would have to be defensive against concurrent runs in the
same build dir.
A simple lock file should suffice. I would be surprised if that was
not there already, but I never checked.
Yes, I think you're right. I haven't checked yet either, but either way it
is necessary.
The key difference is that my proposal is only requested values, so is
minimal.
Yes. But then you need to add cmake -E list_cache that lists all
values. Or how can I find out which values are there in a project?
Indeed.
In the end it is probably easier to either put all that stuff into the
json file or to declare CMakeCache.txt to be a stable read-only file
for the
Re: [cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake)
Tobias Hunger wrote: Hi Stephen, On Sat, Mar 21, 2015 at 10:56 AM, Stephen Kelly steve...@gmail.com wrote: So, the design question I have is: * Is lots of repetition ok in the metadata file? If it can not be avoided, then so be it. It can be avoided at the cost of computation. I thought that was more clear in my mail. The answer will be re-used in many other places. For example, if I have a CMakeLists like add_executable(main file1.cpp ... fileM.cpp ) target_include_directories(main ...) target_compile_definitions(main ...) then we could either write the definitions and includes once (associated with the target), or we could repeat them all M times (once for each file). That could be lots and lots of repetition, repeated N times, once for each configuration. ... or define a group of files, put all the files into that group and add the other relevant flags. If there is a file that needs something different, then just add that as a separate group. This still just pushes a computation requirement to you the consumer of the file. The reason I'm asking about duplication versus computation is because of what you wrote: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12750 Tobias Hunger wrote: Can't we go for a syntax where the files and everything that applies to them are grouped so that there is no need to reimplement the logic found in cmake (with added bugs:-)? If the concern that computation means bugs is the primary concern then we should duplicate a lot of information. Also, the outcome of how we should generate compile flags could have an influence on what we duplicate. Anton will hopefully respond. I don't believe we'll have a huge problem with bugs processing the json. It will have a schema and documentation telling you how to consume it. If it is consumed in multiple steps (eg with processing of your 'source group' idea etc), then I think that's fine. We simply document how it's done. It's no different to any other data format in that sense. A spec is needed to implement the logic of parsing json too, and there are many json parsers out there. I'm sure some have hard-to-reach bugs, but all software has hard-to- reach bugs. In the normal case where all files have the same flags applied the overhead should be close to the minimum. And it still allows for having different settings for different groups of files without the IDE needing to combine settings. E.g. if main.cpp defined TEST=1, while the main-target defined TEST=2, which one will win? I guess this relates to why Anton wants the actual command line. That's undefined behavior. I guess it could be made defined. I filed http://public.kitware.com/Bug/view.php?id=15472 Please do not require all IDEs to implement logic found in cmake. There will always be corner cases where this will fail, leading to a broken code model in the IDE. I agree we don't want to require implementing logic found in CMake. I do think we should be allowed to require 'implementing well defined and specified logic', as you do too judging by your source groups idea. Attached you find something that is close to what I want. I moved the sections in your version of that file around a bit in a text editor, so this might not be valid json:-). Thanks for this. Actually I guess the generated file for that test is too big to do sensible comparisons. I basically want to see a proposal which is more complete than many different ideas of snippets and lots of '...', and I want to see how a consumer would process the file. Maybe we should start with a simpler CMake file. This does not really cover the conditions though, as those were not in your file either. The conditions are handled in my file. Files which do not match the condition all go into the 'excluded files' group. I implemented it that way because of this quote from you: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 I wonder how those kinds of conditions would need to be represented in the ProjectTargets.json file. This is actually a bit too detailed for my needs:-) I want to know which files are part of the project and which are part of the current build. At least Qt Creator does not need information on which conditions to be met for a file to become part of the current build. The 'object sources' are files which will be compiled. The 'excluded' sources will not be compiled, but they are 'part of the project' as you seemed to describe above before. Also, note that in my json file, there is not a generic 'files' property because cmake has more information than just 'files' - it has information about which compiler is used for the files to compile objects, which files are not going to be compiled at all etc. My design gives you that information, but a 'files' array discards it. i do not see configurations as much of a problem in
[cmake-developers] [CMake 0015472]: CMake does not deduplicate defines which have the same name but different value
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15472 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15472 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-24 01:15 CET Last Modified: 2015-03-24 01:15 CET == Summary:CMake does not deduplicate defines which have the same name but different value Description: cmake_minimum_required(VERSION 2.8) project(cmaketest) add_executable(mn main.cpp) target_compile_definitions(mn PRIVATE TESTD=1 TESTD=3) set_source_files_properties(main.cpp PROPERTIES COMPILE_DEFINITIONS TESTD=5) CMake currently passes all of the defines, and the compiler (gcc at least) warns about redefinition. == Issue History Date ModifiedUsername FieldChange == 2015-03-24 01:15 Stephen Kelly New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
