[cmake-developers] [CMake 0015462]: Provide a machine readable way to determine the available generators
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15462
==
Reported By:Stephen Kelly
Assigned To:
==
Project:CMake
Issue ID: 15462
Category: CMake
Reproducibility:have not tried
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2015-03-21 09:17 CET
Last Modified: 2015-03-21 09:17 CET
==
Summary:Provide a machine readable way to determine the
available generators
Description:
As per
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12750
Providing some easily parsed way of determining the available generators for
IDEs would be useful. Eg:
$ cmake -E list_generators
{
generators: [
{
name: Unix Makefiles,
multiconfig: false,
recursive: true,
extraGenerators: [Sublime, CodeBlocks]
},
{
name: Ninja,
multiconfig: false,
recursive: false,
extraGenerators: [Sublime, CodeBlocks]
},
{
name: Xcode
multiconfig: true,
...
}
...
]
}
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-21 09:17 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
[cmake-developers] [CMake 0015464]: target_include_directories(tgt SYSTEM PUBLIC foo) adds include path with -I instead of -isystem
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15464 == Reported By:socantre Assigned To: == Project:CMake Issue ID: 15464 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-21 04:46 EDT Last Modified: 2015-03-21 04:46 EDT == Summary:target_include_directories(tgt SYSTEM PUBLIC foo) adds include path with -I instead of -isystem Description: With the ninja generator and AppleClang on OS X the include flag -I is used instead of -isystem when include directories are added to specific targets A global include_directories(SYSTEM headers) uses the correct -isystem flag Steps to Reproduce: mkdir tmp cd tmp touch main.cpp cat EOF CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(test) add_executable(main main.cpp) target_include_directories(main SYSTEM PUBLIC include) EOF mkdir build cd build cmake -G Ninja .. grep build.ninja -e -I../include Additional Information: -- The C compiler identification is AppleClang 6.0.0.657 -- The CXX compiler identification is AppleClang 6.0.0.657 == Issue History Date ModifiedUsername FieldChange == 2015-03-21 04:46 socantre 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] Generating buildsystem metadata from CMake
Tobias Hunger wrote: Hi Anton, you raised some good points, all of which I agree with:-) On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev anton.mak...@jetbrains.com wrote: * If it is useful to preprocess/compile/assemble individual files from IDEs, as made possible by the Makefiles and Ninja generators, we'll need to design that. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 This is definitely useful, but I’m not sure what kind of information needed here, as I see it, since we already know the files in the project, we can tell make/ninja to simply compile it. You asked me to use cmake --build, so ideally that would be cmake --build . /full/file/path and ideally it would work with all generators without magic in the IDE:-) It is also orthogonal to the metadata of the build itself and can be designed separately. I filed http://public.kitware.com/Bug/view.php?id=15465 if you want to engage in the design or implementation of that. Since I assume that not all build systems will allow to build individual files, you might want to add a flag can_build_individual_files or similar to the metadata that a generator can use to flag the IDE on whether the generated build system can build individual files or not. Then the IDE can hide that option if it is not applicable. Yes. If it's not possible for xcodebuild/VS, then such a property can be added. Noted in http://public.kitware.com/Bug/view.php?id=15462 I would also love to see subprojects:-) CMake allows for them, doesn't it? I don't know what 'subprojects' means to you. An additional though: here only the 'project information' aspect is discussed; though, to be fully machine-frienly, cmake should be able to also generate parseable output (error reports etc), provide the progress, etc. So, just to mull over, probably the discussed design should consider such future direction. Yes, that would be great, but I do not see how cmake can do that: It delegates the actual build to external tools. Anton is talking about output of cmake itself afaik. So in the end during a build we will always have to deal with whatever output the generated buildsystem throws at us:-/ This again somewhat limits the usefulness of allowing the user to pick whichever generator they want: Some will just loose some or all the build issues. Only allow the user to choose a generator for whose make_program you have a parser for. Thanks, Steve. -- 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 0015463]: Provide a way to generate machine readable output during CMake generation
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15463 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15463 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-21 09:38 CET Last Modified: 2015-03-21 09:38 CET == Summary:Provide a way to generate machine readable output during CMake generation Description: As in: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12753 cmake could accept a command line argument to generate output in a different way which is more easy for tools to parse. == Issue History Date ModifiedUsername FieldChange == 2015-03-21 09:38 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
[cmake-developers] CMake and intersphinx
Hello, 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. But thee mapping files were excluded from install by this commit: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c3cf36b3a1388bb9c3a718350c80eae0a41119d Would you consider re-adding these files? Or should 3rd parties host their own documentation sets somewhere? Thanks, Gregor [1] http://sphinx-doc.org/latest/ext/intersphinx.html -- 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 0015465]: Provide a way to build individual files through cmake
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15465 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15465 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-21 10:03 CET Last Modified: 2015-03-21 10:03 CET == Summary:Provide a way to build individual files through cmake Description: CMake has the `--build` command line option providing an abstraction of 'run the build in the specified directory' action. Particular configurations and targets to build can be specified with other options. A new abstraction could be added for 'build the object for sourcefile f'. The Makefiles generator already generates targets for each object in each directory. Those targets are not available from the 'top level' of the build dir. grantlee/make_build$ cmake .. -G Unix Makefiles grantlee/make_build$ make -C templates/lib engine.cpp.o Ninja has native support for 'building the output of a source file' using '^'. grantlee/ninja_build$ cmake .. -G Ninja grantlee/ninja_build$ ninja ../templates/lib/engine.cpp^ grantlee/ninja_build$ cmake --build . --target ../templates/lib/engine.cpp^ Ninja seems to build more dependencies of the object file though too (it runs moc via automoc for example, but make seems not to). It is unknown whether the IDE generators have a way to build an individual file. As the syntax is different for different tools, it could be useful for cmake to provide a unified abstraction. == Issue History Date ModifiedUsername FieldChange == 2015-03-21 10:03 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
Re: [cmake-developers] Generating buildsystem metadata from CMake
Anton Makeev wrote: The other thing that seems troubling to me is that since file, target, language compiler options are split into different parts of metadata, the IDE need to know exactly how to assemble them back into the compiler’s command line (e.g. what flags go first file’s or language’s), duplicating CMake's logic that may be different from version to version and from compiler to compiler. The exact command line is needed to get the actual and precise defines, include search paths etc. from the compiler. Yes. I previously proposed the lang_compile_command to contain information about how to built it: http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html#optional-properties However, I think it might be better to generate something similar to what is currently generated in compile-commands.json into cmake-metadata.json. That is, we would generate (in some context) include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_command: -c -DDEF=\Foo\ -DOTHER_DEF=1 -I/foo -I/opt So, compile_command contains approximately what you can currently get from compile-commands.json. The other properties contain things which are specifically known to be include directories or compile definitions, as javascript arrays. These properties are obviously redundant information, so I wonder if they should be generated at all? Is the compile command I wrote above easy to parse? Or is it sufficiently difficult to parse that this redundant information should be provided? I have no idea if such compile_command can be generated for VS or Xcode, or if constructing such compile commands is done internally by those tools. So, this may not be a portable solution anyway. This would be really helpful indeed, currently, we have to introspect CMakeLists.txt files in order to find the most probably place where new files should be placed (works only in basic cases now). And being able to do so correctly is also crucial for refactoring (e.g. extract class). Given the backtrace, you can navigate up the scope from the most recent frame to get out of any functions, macros or loops. You can then add a target_sources() line directly after that. That algorithm will work for every case (not just basic cases) as far as I can tell and is available with CMake 3.1. * I didn't document the location or directory. I'm not clear on whether it is supposed to be the build location, or the install location(s!), or all of those. It would be useful, though, to have a location of generated files for each target: in case metadata misses some information (and I think it won’t cover every possible need anytime soon), IDE will be able to get if from generated makefiles. Yes, we can at least provide the build location in an obvious way. We can discuss install locations eventually. * I don't generate 'dependencies' (actually the list of files which the buildsystem re-generation depends on) as Aleix did, because there is no well-defined usefulness for that list yet. As Tobias pointed, we at least need to know what files are the part of CMake project, that is, the list of all CMakeLists.txt and *.cmake files, used for generation (ideally, including missing ones, since in that case IDE could be able to tell when missing file is created and refresh the project) As I wrote to Tobias, I'm apprehensive about this, and it would require other work to make cmake parallel safe first. I think if the IDE does not have focus it should not be running 'cmake .' on my behalf. I think if the IDE newly gets focus you can maybe run 'cmake .' at *that* point (after the user is done with their rebase or whatever). That doesn't require giving you a list of files to watch. Maybe I'm missing something though. * Some more information from project() may be relevant, but it's not clear yet. We will likely know more when we have decided the file format and generated some 'interesting' metadata files. Project name, list of the configurations are most needed ones. We also use CMAKE_lang_SOURCEFILE_EXTENSIONS to determine if a given file is potentially source file or not. As CMake already knows which files are 'object sources', the metadata will provide that. Also, the lang extensions is not enough. See the unit test I created and in particular the compiled_as_cxx.c file. This has already been discussed but I give our usage scenario: in CLion we retrieve the list of all build types (aka configurations, Debug, Release etc) From where do you currently retrieve this list? I guess you look at all cache keys named CMAKE_.*_FLAGS_(.*) and list the matches? and list the matches? and then generate project using Makefiles generator for each of them. This is necessary because of several reasons: 1) To be able to correctly build language model, we need to know, when a file is used in several configurations, which means, it's compiler settings
Re: [cmake-developers] Generating buildsystem metadata from CMake
Tobias Hunger wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly
steve...@gmail.com wrote:
* Make it possible for editors/IDEs to allow specifying the configuration
at build-time, where the IDE has that feature, and where a multi-config
generator is available. That is, QtCreator provides user-interface for
choosing debug/release config to build. Currently it can't offer that
when using cmake, because it only allows the use of Makefile or Ninja
generators, in order to make use of the C::B file. QtCreator should be
able to use the Xcode or Visual Studio generators, generate the
metadata file(s), and invoke `cmake --build . --config ${CONFIG}` as
appropriate. Eclipse, Sublime and other editors have similar abilities
to invoke config-specific builds after generation.
We can offer debug/release even with different build directories in
Creator. Those are just labels on the build configuration that
includes the build directory and the configuration to be set up in
that build.
Interesting. Is that already the case in Creator?
For the other build systems it is completely safe to just nuke any
build directory and creator will re-initialize it on the next build.
That is unfortunately not the case with cmake at this time though: If
you nuke a cmake build directory then creator will be completely lost
about how to regenerate the configuration again.
Ah, is this why you asked before for the command line options passed to
cmake before?
Why is it safe with other buildsystems but not cmake to nuke the build dir?
Thanks,
Steve.
--
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] How to handle configurations (Was: Generating buildsystem metadata from CMake)
This seems to be to be a design point which we are blocked on. There are
many different ideas floating around.
I think we need to talk about what would be generated for actual CMakeLists
files, and how tools would parse the result. I suggest starting with the
Tests/Metadata/CMakeLists.txt file in my clone.
I think we need to see both json files and prototype parsers in some
mainstream language or framework (Qt5,Python etc) in order to see whether a
particular proposal is viable.
For my proposal there is already a generated json file checked in as an
example, and a python class for extracting the information.
The requirements for the metadata file include
1) Make it easy to get relevant information without extra computation/logic.
2) Be as DRY as possible.
3) Design something that is possible for cmake to generate.
The first two requirements are obviously in direct conflict.
The third will I'm sure be a limitation compared to what you desire. If some
part of what you propose is impossible, we'll either have to design a way to
make it possible, or accept that it is impossible and update the proposal.
Hopefully this will converge on a design which provides both what is needed
and what is possible.
Implementing it will be easy then.
Tobias Hunger wrote:
Anton Makeev wrote:
As a side note, it seems more natural to me to have one json file with
one or several configurations listed, providing that there is also shared
project info that should be in that files.
something like that:
project: ProjectName
configurations: {
{
name: Debug
targets: {...}
},
{
name: Release
targets: {...}
}
...
}
If we do this, then we have N repetitions of exactly the same data, or
almost exactly the same data. It could be a lot of data. Is that a problem?
For machine reading it is probably not a problem. All the repetition does
make it harder for human reading though of course. I also don't know at what
point does it become slower for the IDE to have to parse ~4-6N times the
amount of data. If the configuration is a 'mode' and only one configuration
is active at a time, you're not using the other stuff anyway.
If you want all the data for all configurations (even inactive ones) for
some reason, then the repetition probably doesn't matter at all. Even with
my proposal of separate files, you would want to load all the files anyway.
Is that the case?
So, the design question I have is:
* Is lots of repetition ok in the metadata file?
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.
I personally prefer minimising the repetition, as I did in the unit test I
pushed to my clone. I have the feeling you guys have not looked at the unit
test I pushed to my clone. Please go ahead and do that if not. Also, when
proposing json formats, please imagine how your proposal would represent the
data in Tests/Metadata/CMakeLists.txt.
Anton, in your proposal, given that realistically Makefile and Ninja
generators are not going to become aware of multiple configurations before
this feature reaches master, what should they generate?
project: ProjectName
configurations: {
{
name: WHAT_WAS_IN_CMAKE_BUILD_TYPE
targets: {...}
}
or
project: ProjectName
targets: {...}
or
project: ProjectName
configuration: WHAT_WAS_IN_CMAKE_BUILD_TYPE
targets: {...}
?
I'd actually prefer having a configurations key with the list of the
configurations an object applies to.
That can be optional if the object is relevant to all configurations
(default in single-configuration generators;-).
This key would then need to be applicable to targets as well as the
group of source files.
So that would be something like this:
Could you post what would be generated by your proposed structure for the
unit test file in my branch?
That would most likely avoid quite a bit of duplication in the file(s).
How does the design goal of 'avoid duplication' weigh against the design
goal of 'don't make me combine multiple properties together to get relevant
information (eg target defines and additional source defines)', in general?
We can either go for one extreme or the other, but I don't think it makes
sense to go for something in between. That would be the worst of both
worlds.
So, for the proposals which are on the table, please either use the
Metadata/CMakeLists.txt file in my clone, or post an alternative together
with the json which you propose we should generate for it, and a prototype
or pseudo-implementation of a parser for that json.
Thanks,
Re: [cmake-developers] CMake and intersphinx
On Saturday 21 March 2015 09:41:06 Gregor Jasny wrote: Hello, 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. But thee mapping files were excluded from install by this commit: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c3cf36b3a1388bb9c3a71835 0c80eae0a41119d Would you consider re-adding these files? Or should 3rd parties host their own documentation sets somewhere? Thanks, Gregor [1] http://sphinx-doc.org/latest/ext/intersphinx.html This would also be useful for the extra-cmake-modules project. 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 0015466]: ninja does not use requested linker
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15466 == Reported By:Benjamin Schindler Assigned To: == Project:CMake Issue ID: 15466 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-21 07:33 EDT Last Modified: 2015-03-21 07:33 EDT == Summary:ninja does not use requested linker Description: In a project, I set CMAKE_LINKER to /usr/bin/ld.gold. Yet, when I build my project, the link step uses /usr/bin/c++ to link the project. == Issue History Date ModifiedUsername FieldChange == 2015-03-21 07:33 Benjamin SchindlerNew 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
[cmake-developers] [CMake 0015467]: add_custom_target ALL option regression
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15467 == Reported By:Zhihao Yuan Assigned To: == Project:CMake Issue ID: 15467 Category: CMake Reproducibility:always Severity: minor Priority: high Status: new == Date Submitted: 2015-03-21 22:04 EDT Last Modified: 2015-03-21 22:04 EDT == Summary:add_custom_target ALL option regression Description: It seems that the ALL option is not making the target to run before other targets after cmake 3.1. The cmake file is here: https://github.com/lichray/nvi2/blob/master/build/CMakeLists.txt#L49 I'm generating header files with add_custom_commend and using add_custom_target to run those commands. Steps to Reproduce: See https://github.com/lichray/nvi2/issues/29 == Issue History Date ModifiedUsername FieldChange == 2015-03-21 22:04 Zhihao YuanNew 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
