Re: [cmake-developers] Extracting target metadata, IDE integration
Sorry, I am a bit late with replying to this... I do not follow this
list too closely and got distracted by mails in between where I could
not contribute anything:-/
On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly steve...@gmail.com wrote:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
CMake only knows whether the WIN32_EXECUTABLE property has been set on a
target.
http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
The property is harmless on non-Windows, so KDE sets it on non-Windows for
gui applications IIRC, but others may not.
This is a hint only.
If it works correctly it is nice, otherwise the user will have to
toggle some checkbox
to change it to his or her liking.
Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.
If the linker flags were provided, you would have to parse them. Maybe a
runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
the content passed to the option -rpath. I have no idea if similar
information can be acquired for MSVC/Windows. As Nils said, CMake might not
know the location of the import library.
If CMake knows the locations, then put them in, please.
If not then there is little you can do, is there?
Combined with CMAKE_EXPORT_COMPILE_COMMANDS this should allow for a
pretty good integration into creator. Ideally the exported compile
commands would be a bit more aggregated along the lines of the
following list of files will be build using these defines/include
paths/flags, just because that would be way shorter and most likely
faster to parse.
What would that looks like? I guess listing the sources in a target together
with its includes/defines should be possible, together with extra per-source
defines, if present?
[
name : testc1
sources : [foo.cpp, bar.cpp]
defines : [BUILD_TEST=1, QT_CORE_LIB]
includes : [/opt/bat/include, /usr/include/qt5]
extraDefines : {
foo.cpp : [EXTRA_FOO=1]
}
]
I was thinking more along the lines of a somewhat aggregated
CMAKE_EXPORT_COMPILE_COMMANDS, but this is even better:-)
But why not have groups of sources?
[
name: testc1
sourceGroups [
{
sources: [ foo.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB, EXTRA_FOO=1],
includes: [/opt/bat/include, /usr/include/qt5]
},
{
sources: [ bar.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB],
includes: [/opt/bat/include, /usr/include/qt5]
}
]
]
Would be simpler to parse for us.
With this target description and the compile commands there is just
one piece of the puzzle missing for a great Qt Creator integration: We
need to generate a list of files that are part of the project. I
currently do not know how to extract that list from cmake. This list
must include all the header files that belong to the project, which is
what makes this hard to get this information from cmake -- at least at
the time I stopped working with cmake.
Afaik, CMake does not know all the files included by your cpp files.
However, some buildsystems can add them to the list of sources if desired
for better IDE integration.
https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
That is the big issue I have with CMake... it makes it impossible to use
CMakeLists.txt as a sole source of project configuration.
Creator tries to not need any extra files to manage the project, so this
hits us pretty hard.
Ideally we could get the list of files that belong to the project in
general and the files that are actually part of the currently
configured built.
In CMake master at least, the user can list config-specific files
declaratively. Eg, add the foo_debug.cpp file only in the debug
configuration:
add_library(foo
foo.cpp
$$CONFIG:Debug:foo_debug.cpp
)
But how can I know that something_win.h will not be used when
building on my Linux box?
The current style is indeed difficult to parse, where that might be inside
an if() inside a macro etc. Again though, CMake master will allow users to
do better:
add_library(foo
foo.cpp
$$PLATFORM_ID:Windows:foo_win.cpp
)
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.
One option would be to write them directly to the
json, instead of, for example, creating individual lists for each
configuration, and expecting the consumer to evaluate the expressions. A
possible problem with that is that consumers would have to transitively
evaluate each property over the link closure. Apart from the potential for
bugs,
Re: [cmake-developers] Extracting target metadata, IDE integration
On 10/17/2014 06:44 AM, Tobias Hunger wrote: On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly steve...@gmail.com wrote: Afaik, CMake does not know all the files included by your cpp files. However, some buildsystems can add them to the list of sources if desired for better IDE integration. https://gitorious.org/grantlee/grantlee/commit/3eb40cf94 That is the big issue I have with CMake... it makes it impossible to use CMakeLists.txt as a sole source of project configuration. Creator tries to not need any extra files to manage the project, so this hits us pretty hard. We've discussed this in the past a few times. One solution is for the project spec to be in a declarative format, e.g. a JSON document. The spec would not be in a CMakeLists.txt but could be loaded by a command invoked from it. Then it could also be loaded and manipulated separately by IDEs or other tools. So, rather than having CMake generate a project spec file from the CMakeLists.txt files, we have CMakeLists.txt files load a project spec file. The declarative information goes in the project spec file, and imperative things like try_compile can be done in the CMake config step. The imperative step also loads the project spec and evaluates the declarations based on discovered information about the target platform. Other than this basic design, no one has taken the time to design such a format. -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 0015210]: CMakeFindBinUtils.cmake not re-run when cache is deleted
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15210 == Reported By:Clinton Stimpson Assigned To: == Project:CMake Issue ID: 15210 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-10-17 13:36 EDT Last Modified: 2014-10-17 13:36 EDT == Summary:CMakeFindBinUtils.cmake not re-run when cache is deleted Description: If I run cmake to create a build tree, then delete the CMakeCache.txt file and re-run cmake, the cache variables from CMakeFindBinUtils.cmake are not restored. Modules/Platform/Darwin.cmake and Modules/Platform/Windows-MSVC.cmake both contain hacks to restore some cache variables. In my case, a missing CMAKE_STRIP prompted this bug report because it was possible to create packages containing debug symbols. Steps to Reproduce: With root/CMake and root/build: cmake ../CMake mv CMakeCache.txt CMakeCache.txt.bak rm CMakeCache.txt cmake ../CMake diff -u CMakeCache.txt.bak CMakeCache.txt to see all of the missing variables. == Issue History Date ModifiedUsername FieldChange == 2014-10-17 13:36 Clinton StimpsonNew 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] Xcode Project: Support for DevelopmentTeam
Somewhere starting in Xcode 4 or 5, Apple added a Team dropdown to the
General tab of a target. The developer can select a development team there,
which results in a bunch of useful things, most importantly: Xcode
automatically updates the devices list in the Member Center and the
currently fitting iOS Team Provisioning Profile. This creatly simplyfies
management of development devices.
It would be very nice if CMake supported setting this option. A look at the
project.pbxproj reveals that this setting is stored in the 'attributes' in
the PBXProject section:
3B69B74659794A7B9F0C2B71 /* Project object */ = {
isa = PBXProject;
attributes = {
BuildIndependentTargetsInParallel = YES;
TargetAttributes = {
26E66AE0CD2341D58DBF6E8B = {
DevelopmentTeam = 10 character Team ID;
};
};
};
In the CMake source I noticed that 'BuildIndependentTargetsInParallel' is
already getting set. This could be extendet to add the 'TargetAttributes'
section. Note that the ID used in there (26E66AE0CD2341D58DBF6E8B in the
example) is the ID of the 'main' target, i.e. the one with the name of the
project.
The 10 character Team ID can be found by the developer in the member center
under Your Account. This could be set with a CMake flag.
Thanks,
Fabian
--
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
