Re: [cmake-developers] Review request: Ninja-EXPORT_COMPILE_COMMANDS
Peter Collingbourne wrote: On Sun, May 13, 2012 at 11:59:20PM +0200, Stephen Kelly wrote: Stephen Kelly wrote: Furthermore, there is no need to make paths within the build directory absolute. Each command must be invoked from the home output directory (i.e. the build root directory), so each command's directory attribute should be set to that directory, rather than the start output directory as in your patch. Fixed now, If I understood you correctly. I've pushed this to the CMake stage repo now. Peter, could you verify that I should always use the same directory for the directory JSON property as I do in the patch? Yes, this looks fine now. Great, thanks. I've merged it to next. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Target usage requirements and conventions
Alexander Neundorf wrote: On Sunday 13 May 2012, Stephen Kelly wrote: Stephen Kelly wrote: Hi there, The topic of 'target usage requirements' has come up several times. It's something I'd like to work further towards in CMake 2.8.9. I have created a wiki page on the KDE wiki (there for my convenience mostly) so that we can discuss the design, implementation and implications. http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements Thanks for any comments, Hi there, Thanks for the feedback on this proposal so far. I have updated the wiki page to remove any reference to target_use_package() or functionality depending on conventions of variable names, or finding packages etc. The proposal as written now expects the caller to supply targets, and never expects a package name or a prefix. The page is now focussed on creation of a target_use_targets() command which operates on targets which are in scope because either they were created in the same buildsystem, or they were imported. It would be possible to revisit the target_use_package() idea in the future, but that is no longer the aim of the proposal. The target_use_targets() is already a useful enough concept to aim for. Great :-) The remaining (I think) open question regards what form the generator expressions should take so that they can represent multiple dimensions. Some comments: will target_use_target() also need PRIVATE and PUBLIC keywords as target_link_libraries() has now ? Yes. It may even have to be more granular than that. For example it might be necessary to have include_directories public in a dependency without having public linking (eg if a header is #included which contains defines used in my headers). I'm sure that's rare though, so I think we simply need to choose whether to be fully granular, fully monolithic, or somewhere in between. Currently I'm leaning towards fully monolithic. If a target depends publically on another target in any way, that is PUBLIC. In installed config/targets files, the include directories must be relocatable. Added to the wiki. I think that might be tricky to get right. Cross compiling: currently the assumption is that find_library()/find_path() will find files for the target, so inside the build by default everything is for the target. I don't think this needs extra handling here. Sounds good. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding logic to CMake for -fPIE and -fPIC
On 05/17/2012 08:36 AM, Stephen Kelly wrote:
Done and re-pushed to my clone. I still have to write the unit tests, but I
think it can be reviewed again at this point.
Great start. Here are some comments.
The Update the documentation of IMPORTED_LOCATION to match the code. commit
has an incorrect message. You're modifying the MAP_IMPORTED_CONFIG_CONFIG
docs. Also, the original wording the commit changes is correct under the
assumption that the property is set, and if the property is not set then why
should its docs apply? Anyway, I think it can be made even more clear than
your proposed wording by using
If this property is set and no matching configurations...
-
The LanguageToCachedSharedLibFlags ivar would be better named
LanguageToOriginalSharedLibFlags IMO. Also please add a comment
where they are set to explain why (just ref the policy).
The proposed CMP0018 summary should prefer POSITION_INDEPENDENT_CODE
instead of COMPILE_OPTIONS, no? The property is part of the public
interface the user can set/get. The COMPILE_OPTIONS values are impl
details. Also the documentation appears to be cut-n-pasted from another
policy. Please fill in the details.
The docs of POSITION_INDEPENDENT_CODE are incorrect. The last sentence
should be This property is true by default for SHARED and MODULE library
targets and false otherwise..
Your logic should use GetSafeDefinition instead of GetDefinition before
storing the result in a std::string because the latter returns NULL if
not set.
AddPositionIndependentFlags shouldn't care whether the library is
shared or not, right? If the property is true then we want the flags.
Perhaps:
std::string picFlags;
if (targetType == cmTarget::EXECUTABLE)
{
std::string flagsVar = CMAKE_;
flagsVar += lang;
flagsVar += _COMPILE_OPTIONS_PIE;
picFlags = this-Makefile-GetSafeDefinition(flagsVar.c_str());
}
if(picFlags.empty())
{
std::string flagsVar = CMAKE_;
flagsVar += lang;
flagsVar += _COMPILE_OPTIONS_PIC;
picFlags = this-Makefile-GetSafeDefinition(flagsVar.c_str());
}
if(!picFlags.empty())
{
this-AppendFlags(flags, picFlags.c_str());
}
There is a lot more to adding a policy than just
GetPolicyStatus(cmPolicies::CMP0018) == cmPolicies::OLD
Look at some of the other policies. You need to handle all the possible
values. If it is WARN then you need to produce the warning and treat as
OLD behavior. See the switch() statements used for others.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Target usage requirements and conventions
On 05/17/2012 09:25 AM, Stephen Kelly wrote: $IF($CONFIGURATION MATCHES Debug AND $LANGUAGE STREQUALS CXX)... I'm not sure what should go in the ... part though. Some syntax to delimit the then/else values would be needed. I'm not sure else() and endif() are needed as additional expressions could be added for those. We may not need the else part but we still need a strict and extensible syntax to delimit the value in the ... part above. Perhaps we can get object-orientated: populate_target_usage_requirements( NAME fooRequirements [PUBLIC|PRIVATE] INCLUDE_DIRECTORIES /foo/bar INCLUDE_DIRECTORIES /bat/bug IF $CMAKE_BUILD_TYPE MATCHES Debug COMPILE_DEFINITIONS -DQT_CORE_LIB COMPILE_DEFINITIONS -DQT_GUI_LIB IF BUILD_TESTING ) I think it will be hard to define the reach to the left of IF in non-trivial cases, especially when the arguments are built up inside a variable and some parts might end up empty. Also the result of this command will still need to be stored in the property as some kind of generator expression, so we still need to define such an expression. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Handling of Config specific imported targets?
Brad King wrote:
On 05/17/2012 09:41 AM, Stephen Kelly wrote:
Great, so choosing the correct imported configuration a solved problem.
I'll point the documentation in of the Qt 5 CMake stuff to that so.
Note that MAP_IMPORTED_CONFIG_CONFIG should not be set by package
configuration files. It should only be set in the CMakeLists.txt files
of the project *loading* them. Only the application knows its own list
of configurations. The documentation of the package should list the
valid configurations to which one may map.
Am I right that it is appropriate to create imported targets without a
_${Config} though?
It shouldn't be necessary to create the non-config one. If only
IMPORTED_LOCATION_DEBUG and IMPORTED_LOCATION_RELEASE are set and not
IMPORTED_LOCATION then the default behavior will still choose one of
the available configurations. Just be sure to list all the available
configurations in IMPORTED_CONFIGURATIONS.
Yes, ok I'll take that approach.
I'll also reverse the order of creating those IMPORTED_CONFIGURATIONS too so
that Windows users will get Release unless they use Debug or do the mapping
stuff. That way they will also get the Release version if they use
RelWithDebInfo or MinSizeRel, which seem to be built into CMake.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Target usage requirements and conventions
Brad King wrote:
On 05/17/2012 09:25 AM, Stephen Kelly wrote:
$IF($CONFIGURATION MATCHES Debug AND $LANGUAGE STREQUALS
CXX)...
I'm not sure what should go in the ... part though. Some syntax to
delimit the then/else values would be needed.
I'm not sure else() and endif() are needed as additional expressions
could be added for those.
We may not need the else part but we still need a strict and extensible
syntax to delimit the value in the ... part above.
I guess you mean something like ENDIF won't be good enough. I guess it might
not be extensible if you want to do something else than if...endif, but I'm
not certain what you have in mind with 'extensible' or if you have any ideas
of how it might need to be extended.
Perhaps we can get object-orientated:
populate_target_usage_requirements(
NAME fooRequirements
[PUBLIC|PRIVATE]
INCLUDE_DIRECTORIES /foo/bar
INCLUDE_DIRECTORIES /bat/bug IF $CMAKE_BUILD_TYPE MATCHES Debug
COMPILE_DEFINITIONS -DQT_CORE_LIB
COMPILE_DEFINITIONS -DQT_GUI_LIB IF BUILD_TESTING
)
I think it will be hard to define the reach to the left of IF in
non-trivial cases
ENDIF again no good here?
, especially when the arguments are built up inside
a variable and some parts might end up empty.
You mean like this:
if (some_option)
set(include_condition IF $CMAKE_BUILD_TYPE MATCHES Debug ENDIF)
endif()
populate_target_usage_requirements(
...
INCLUDE_DIRECTORIES /bat/bug ${include_condition}
)
Also the result of this
command will still need to be stored in the property as some kind of
generator expression, so we still need to define such an expression.
Yes. My idea is based on the properties with generator expressions not being
so convenient to edit at runtime as in the example I gave before, but
providing this API to wrap the less convenient 'generator containing a
boolean expression' elements.
But indeed, this alone does not solve the problem of creating a strict
enough syntax for storage of the properties.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013234]: Ninja: Add support for IMPLICIT_DEPENDS in add_custom_command
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13234 == Reported By:Mathias Gaunard Assigned To: == Project:CMake Issue ID: 13234 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-05-17 10:47 EDT Last Modified: 2012-05-17 10:47 EDT == Summary:Ninja: Add support for IMPLICIT_DEPENDS in add_custom_command Description: It would be nice if Ninja supported IMPLICIT_DEPENDS in add_custom_command like Makefile generators. I personally use this feature when building precompiled headers. In the current state of affairs, I have to disable PCH generation and usage when using Ninja. == Issue History Date ModifiedUsername FieldChange == 2012-05-17 10:47 Mathias GaunardNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] conditionals in generator expressions (was: Target usage requirements and conventions)
On 05/17/2012 10:31 AM, Stephen Kelly wrote:
We may not need the else part but we still need a strict and extensible
syntax to delimit the value in the ... part above.
not certain what you have in mind with 'extensible' or if you have any ideas
of how it might need to be extended.
The structure so far is
$IF(${cond})...
the ${cond} part we are saying is the CMake language IF expression syntax.
However, after the ')' in the normal language comes other commands with
known syntax. In the generator expression case the ... contains a *value*.
I don't think it is so readable though:
$IF(${cond})${value}
Perhaps something like
$IF(${cond}) THEN(${value})
Also, what if ${cond} or ${value} has a '' in it? All previous generator
expressions have very limited content inside $. Now we're talking about
arbitrary content. We need encoding, escaping, etc. It is a can of worms.
Yes. My idea is based on the properties with generator expressions not being
so convenient to edit at runtime as in the example I gave before, but
providing this API to wrap the less convenient 'generator containing a
boolean expression' elements.
But indeed, this alone does not solve the problem of creating a strict
enough syntax for storage of the properties.
Let's start with the generator expression part and consider helpers later.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] conditionals in generator expressions (was: Target usage requirements and conventions)
I don't think this conditional stuff in generator expressions is a good
idea at all.
It's going to be ugly and very hard to read, and make people hate the CMake
language even more than they already do.
If there's any way at all that supports what we want but does not require
conditionals, then we should go with that way instead.
Or maybe I'm just getting old...?
On Thu, May 17, 2012 at 10:49 AM, Brad King brad.k...@kitware.com wrote:
On 05/17/2012 10:31 AM, Stephen Kelly wrote:
We may not need the else part but we still need a strict and
extensible
syntax to delimit the value in the ... part above.
not certain what you have in mind with 'extensible' or if you have any
ideas
of how it might need to be extended.
The structure so far is
$IF(${cond})...
the ${cond} part we are saying is the CMake language IF expression syntax.
However, after the ')' in the normal language comes other commands with
known syntax. In the generator expression case the ... contains a
*value*.
I don't think it is so readable though:
$IF(${cond})${value}
Perhaps something like
$IF(${cond}) THEN(${value})
Also, what if ${cond} or ${value} has a '' in it? All previous generator
expressions have very limited content inside $. Now we're talking about
arbitrary content. We need encoding, escaping, etc. It is a can of worms.
Yes. My idea is based on the properties with generator expressions not
being
so convenient to edit at runtime as in the example I gave before, but
providing this API to wrap the less convenient 'generator containing a
boolean expression' elements.
But indeed, this alone does not solve the problem of creating a strict
enough syntax for storage of the properties.
Let's start with the generator expression part and consider helpers later.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Reason of Fortran include directories /config?
Thanks very much for the feedback. I will look into the module stuff, where the compiler puts it etc. Petr On Wed, May 16, 2012 at 10:24 PM, Brad King brad.k...@kitware.com wrote: On 05/10/2012 03:25 AM, Petr Kmoch wrote: we're using cmake to generate Intel Fortran .vfproj files and some of my developers were asking why include directories in the project always include X and X/config_name for every directory X specified via include_directories(). Looking at cmake source code, the lines responsible seem to be 829-837 of cmLocalVisualStudio7Generator.cxx The lines were added as part of the original Fortran support: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=10c91ded#patch6 I would be really interested in the reason for this behaviour. Could anyone shed some light onto this for me? As Michael pointed out this probably has to do with Fortran 90 .mod files. The Intel compiler loads them from the include files search path. Contents of .mod files may be configuration-specific so perhaps the compiler puts them in the per-config output directories. I was not personally involved in adding those particular lines though. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking to libraries that depend on other libraries
Hi David, there's a target property LINK_INTERFACE_LIBRARIES (and per-configuration variants) which can be used for this purpose. Starting with 2.8.7, target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as a new argument mode, setting the property instead of linking. Petr On Wed, May 16, 2012 at 11:19 PM, David Doria daviddo...@gmail.com wrote: I have a library, libA, that depends on another library, libB, with this structure: My Program - libA - libB In my program, if I only link to libA, I get linker errors that it can't find things in libB, and these errors are fixed if I also link My Program to libB. This makes sense, but is there any way to avoid it with CMake? That is, a command that I can put in libA (created with add_library) that says when something links to me (libA), also/automatically link it to libB? Thanks, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] copy dependant shared libs locally
Hello, I would like to trace shared library dependencies between targets (and also to external packages) and then copy required dll's to output bin directory (so that they are immediately available, without PATH editing) in the post-build. However, for debug configuration, I need to copy debug dll's (usually with 'd' suffix) and for release configuration - release dll's. I can copy files to run-time directory using add_custom_command, but how could I make a distinction for the release-debug files? Thanks, -- Daniel Krikun -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking to libraries that depend on other libraries
Hi Am Donnerstag, 17. Mai 2012 schrieb Petr Kmoch : Hi David, there's a target property LINK_INTERFACE_LIBRARIES (and per-configuration variants) which can be used for this purpose. Starting with 2.8.7, target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as a new argument mode, setting the property instead of linking. Actually using link_interface_libraries in target_link_libraries works already in 2.6.4 I believe, since KDE uses that and requires that cmake version at the moment. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] copy dependant shared libs locally
Hi Daniel. In general, that is not possible with cmake at the moment. What I currently do is have two custom targets, one for copying to debug, one for copying to release. It's annoying that both get run in either configuration, but I couldn't find a better way around it. There are some bugreports in cmake's tracker, you might find some inspiration there: http://public.kitware.com/Bug/view.php?id=9974 http://public.kitware.com/Bug/view.php?id=12877 Petr On Thu, May 17, 2012 at 9:12 AM, Daniel Krikun krikun.dan...@gmail.com wrote: Hello, I would like to trace shared library dependencies between targets (and also to external packages) and then copy required dll's to output bin directory (so that they are immediately available, without PATH editing) in the post-build. However, for debug configuration, I need to copy debug dll's (usually with 'd' suffix) and for release configuration - release dll's. I can copy files to run-time directory using add_custom_command, but how could I make a distinction for the release-debug files? Thanks, -- Daniel Krikun -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] target_link_libraries chain dynamic-static
Hello! I use 2.8.8 and my build chais is following: I have 3 static libs - A.a, B.a, C.a. I'm creating new D.so (add_library .. SHARED .. ) with limited set on functions from static libs (linking -lA -lB -lC to resolve functions). Then I'm creating application, wich use D.so as main library. I'm linking it with target_link_libraries(target D.so). But finally, my link cmdline is following: -o application -lD -lA -lB -C. But I want to link only one shared lib - D.so! As I understand this is results of caching libs. How I can resolve this? Thanks! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries chain dynamic-static
Hi Anton, you should look into target property LINK_INTERFACE_LIBRARIES (and its per-configuration variants) which controls transitive linking. target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as an argument mode, which sets the property instead of linking. Petr On Thu, May 17, 2012 at 3:07 PM, Anton Sibilev anton.sibi...@gmail.com wrote: Hello! I use 2.8.8 and my build chais is following: I have 3 static libs - A.a, B.a, C.a. I'm creating new D.so (add_library .. SHARED .. ) with limited set on functions from static libs (linking -lA -lB -lC to resolve functions). Then I'm creating application, wich use D.so as main library. I'm linking it with target_link_libraries(target D.so). But finally, my link cmdline is following: -o application -lD -lA -lB -C. But I want to link only one shared lib - D.so! As I understand this is results of caching libs. How I can resolve this? Thanks! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Secret precompiled header support?
Hey Bill, First of all apologies if I have offended anyone, my goal wasn't to disrespect CMake or anyone's efforts they put into it. Perhaps I made a poor choice of words. What I was trying to convey with my use of the word professional was to say that there are areas that seem inconsistent or odd to use, and by making those more consistent it seems more professional. Perhaps instead of saying professional, I should just say consistent :) Normally when you encounter professional software (that is, software that you pay for, that is generally well designed and maintained by a single entity), it has a consistent feel. Open source naturally can feel inconsistent because of the large number of contributions, which sometimes don't follow the same implementation patterns. I hope that clarifies what I meant. An example, as I had stated, is general compiler flag support. For example, we have convenience methods for includes and preprocessor definitions, but PCH and warning levels does not have such a thing. Outside of the mailing list, I am trying to sell the company I'm working for on using CMake. Every day, all I do is say great things about CMake and I even mention you and David personally to people I work with and speak highly of Kitware. So trust me, I really do talk a lot more about the positives than the negatives. However, it's not as useful to start a post here on the mailing list about the great things that have already been done. It's nice to show appreciation but such a discussion isn't as productive as discussing what to do next or what to improve. After all, I see the mailing list as a place to get help and to discuss future work. The discussion has gotten quite off track. I just wanted to let everyone know that never during the discussion was I upset or intended to come off as hostile, that's the tricky thing about text. You can't really know what the person is really feeling or saying :) On a more relevant and productive note, I'd love to help add new commands or whatever to help make supporting different compiler features more compiler-agnostic, but there are a couple of issues: 1. I am only a Windows developer, so I can only really provide solutions targeting MSVC. Such a patch would not be useful as I'd have to handle a wide range of compilers such as ARM and GCC. 2. Creating a new command for every single compiler flag or feature can get out of control easily and quickly become unmaintainable and messy to use and document. I think this is where the Boost modularization discussion becomes useful, because they have outlined in detail some great ideas to creating a uniform sort of meta-language to supporting a finite number of compiler options without adding bloat to the commands list. If you haven't had a chance to look this over, it would make for a great read, especially for the more experienced CMake developers like you and David. It's a tough issue to tackle but at least the majority of people here recognize improvement is in order. The problem is, it's a tall order. On Wed, May 16, 2012 at 8:47 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 5/16/2012 3:49 PM, Robert Dailey wrote: involved with CMake will help push Kitware to realize how serious people are taking their products and maybe they'll make a move to professionalize them. So, I do take offense to this language. Kitware does take CMake seriously and we are always moving to make it better. However, since it is an open source project, we do not get any direct revenue from CMake. We do of course receive revenue from companies and agencies willing to hire us to implement features or develop CMake build systems for them. If your company wants generic pre-compiled header support, we would love for you to hire Kitware to implement it. If you are working on an open source project and you would like to contribute pch support that would be great as well. I think the fact that you are able to do what you need to do, even with a bit of extra work speaks to the professionalism and flexibility of CMake. If you were unable to create a working build system that supported PCH and the other features you found missing in CMake, that would be a failure of CMake. If at the moment CMake does not have an elegant way to achieve a particular goal, I don't think that makes it an unprofessional software tool. I was using the word serious here as more of a verb, not an adjective. I'm saying that boost considering CMake is an indication of how people are taking CMake seriously. In other words, popular communities are depending on CMake (or gathering interest in) which makes CMake a tool taken more seriously. Understand now? Not really... KDE (one of the world's largest open source projects) adopted CMake in 2006, and they have been a great community to work with. We have, when KDE goals have intersected with some of our paying customers, been able to implement
Re: [CMake] Linking to libraries that depend on other libraries
On Thu, May 17, 2012 at 2:18 AM, Petr Kmoch petr.km...@gmail.com wrote: Hi David, there's a target property LINK_INTERFACE_LIBRARIES (and per-configuration variants) which can be used for this purpose. Starting with 2.8.7, target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as a new argument mode, setting the property instead of linking. Petr Petr, I tried the following, but in both cases (target_link_libraries and set_target_properties) I still get a linker error that it can't find TestB(). cmake_minimum_required(VERSION 2.6) PROJECT(Test) add_library(TestB TestB.cpp) # TestA depends on TestB add_library(TestA TestA.cpp) #target_link_libraries(TestA LINK_INTERFACE_LIBRARIES TestB) set_target_properties(TestA PROPERTIES LINK_INTERFACE_LIBRARIES TestB) # I want to link to TestA and have it automatically also link to TestB add_executable(Test Test.cpp) target_link_libraries(Test TestA) I have uploaded the entire demo project here: http://homepages.rpi.edu/~doriad/Upload/TestCMake.tar.gz Any ideas? Thanks, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] install command installing symbolic links rather than files
In our build tree, we have symbolic links to COTS libraries located elsewhere. When we do the install, it copies these symbolic links into the run tree when we would actually like a copy of the source of these links (the file) in the run tree. Is there a way to make the install command copy the file that is the source of the symbolic link rather than the symbolic link itself? Gantry York Boeing/KinetX Iridium SCS Development Team -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to handle a submodule existing twice in a project?
I have a main project (called Test) that has two submodules, TestA and TestB. TestA also has a submodule, which is exactly the same TestB. So there is a directory Test/TestB as well as Test/TestA/TestB In TestA/CMakeLists.txt, I have add_subdirectory(TestB). In Test/CMakeLists.txt, I have add_subdirectory(TestA) as well as add_subdirectory(TestB). CMake complains that it cannot create TestB because another target with the same name already exists (which it does). What is the right way to handle this? I always assume that TestB is identical in both places (which might not be a great assumption...), so I guess I just want, in both places, to say include TestB if it already hasn't been included. I tried to do that by replacing the add_subdirectory(TestB) calls with: if(NOT TestB_SOURCE_DIR) add_subdirectory(TestB) endif() but then the linker complains that it can't find TestB. I have uploaded a demo project here: http://homepages.rpi.edu/~doriad/Upload/TestCMake2.tar.gz Thanks! David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking to libraries that depend on other libraries
Hi, On Thu, May 17, 2012 at 10:50 PM, David Doria daviddo...@gmail.com wrote: On Thu, May 17, 2012 at 2:18 AM, Petr Kmoch petr.km...@gmail.com wrote: Hi David, there's a target property LINK_INTERFACE_LIBRARIES (and per-configuration variants) which can be used for this purpose. Starting with 2.8.7, target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as a new argument mode, setting the property instead of linking. Petr Petr, I tried the following, but in both cases (target_link_libraries and set_target_properties) I still get a linker error that it can't find TestB(). cmake_minimum_required(VERSION 2.6) PROJECT(Test) add_library(TestB TestB.cpp) # TestA depends on TestB add_library(TestA TestA.cpp) #target_link_libraries(TestA LINK_INTERFACE_LIBRARIES TestB) set_target_properties(TestA PROPERTIES LINK_INTERFACE_LIBRARIES TestB) You forgot to link TestA to TestB here, I guess your c++ code currently does not actually expose any dependency? Thats why cmake doesn't include TestB when linking the executable. The LINK_INTERFACES_LIBRARIES only helps cmake to decide when a particular library doesn't need to be added to the linker-command for the executable. By default cmake will link the executable against the libraries specified by you and any libraries these link to - recursively. The property just allows to disable this behaviour by defining which dependent libraries a given library exposes in its public API and hence which dependent libraries an executable might need to link against in addition to the main library. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle a submodule existing twice in a project?
Hi, On Thu, May 17, 2012 at 11:20 PM, David Doria daviddo...@gmail.com wrote: I have a main project (called Test) that has two submodules, TestA and TestB. TestA also has a submodule, which is exactly the same TestB. So there is a directory Test/TestB as well as Test/TestA/TestB In TestA/CMakeLists.txt, I have add_subdirectory(TestB). In Test/CMakeLists.txt, I have add_subdirectory(TestA) as well as add_subdirectory(TestB). Why are you doing that? If TestB is always available as sub-dir under TestA it doesn't make much sense to also add it as a subdirectory of the parent of TestA - IMHO. Test/CMakeLists.txt can still use all targets from TestB, since target names are always valid across the complete project. Since TestA is a submodule, it should always be present in the sources anyway. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle a submodule existing twice in a project?
Why are you doing that? If TestB is always available as sub-dir under TestA it doesn't make much sense to also add it as a subdirectory of the parent of TestA - IMHO. Test/CMakeLists.txt can still use all targets from TestB, since target names are always valid across the complete project. Since TestA is a submodule, it should always be present in the sources anyway. Andreas I use functionality of TestB in Test. If TestA decides to remove TestB, then Test will break. I was trying to hide the implementation of TestA by requiring both TestA and TestB to be submodules of Test, regardless of whether or not TestA has TestB as a submodule of its own. See what I mean? David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Build shared and static in one build
Hi, How does one gey a setup where both a static and shared version of a library is built in 'one go' in CMake? Is that possible? -totte -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install command installing symbolic links rather than files
2012/5/17 EXT-York, Gantry gantry.y...@boeing.com: In our build tree, we have symbolic links to COTS libraries located elsewhere. When we do the install, it copies these symbolic links into the run tree when we would actually like a copy of the source of these links (the file) in the run tree. What is the run tree? The tree resulting from installation? I don't think that having a symlink to external in build tree is a good practice, why are you doing that? May be you could 1) configure_file(COPYONLY) the COTS lib instead of symlink or 2) use an IMPORTED library using: add_library(name SHARED|STATIC|MODULE|UNKNOWN IMPORTED) set_property(TARGET name PROPERTY IMPORTED_LOCATION /path/to/name) cmake --help-command add_library http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets Is there a way to make the install command copy the file that is the source of the symbolic link rather than the symbolic link itself? I don't think so, if you want that I think you should copy the target at CMake time as in suggested in method 1). If you want to bundle those external libs with your software, may be you should have a look at BundleUtilities.cmake cmake --help-module BundleUtilities -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: Build shared and static in one build
-- Forwarded message --
From: Eric Noulard eric.noul...@gmail.com
Date: 2012/5/18
Subject: Re: [CMake] Build shared and static in one build
To: to...@dunescientific.com
2012/5/18 Totte Karlsson to...@dunescientific.com:
Hi,
How does one gey a setup where both a static and shared version of a library
is built in 'one go' in CMake? Is that possible?
set(LIBSRC blah.c bouh.c)
add_library(MyLib SHARED ${LIBSRC})
add_library(MyLib-static STATIC ${LIBSRC})
set_target_properties(MyLibStatic PROPERTIES OUTPUT_NAME MyLib)
should work
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle a submodule existing twice in a project?
Hi, On Thu, May 17, 2012 at 11:36 PM, David Doria daviddo...@gmail.com wrote: Why are you doing that? If TestB is always available as sub-dir under TestA it doesn't make much sense to also add it as a subdirectory of the parent of TestA - IMHO. Test/CMakeLists.txt can still use all targets from TestB, since target names are always valid across the complete project. Since TestA is a submodule, it should always be present in the sources anyway. Andreas I use functionality of TestB in Test. If TestA decides to remove TestB, then Test will break. I was trying to hide the implementation of TestA by requiring both TestA and TestB to be submodules of Test, regardless of whether or not TestA has TestB as a submodule of its own. See what I mean? Yeah. Well, in that case I'd simply check for the TestB target thats defined in TestB/CMakeLists.txt as condition for the top-levels add_subdirectory: if(NOT TARGET TestB) add_subdirectory(TestB) endif() That should work. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle a submodule existing twice in a project?
Yeah. Well, in that case I'd simply check for the TestB target thats defined in TestB/CMakeLists.txt as condition for the top-levels add_subdirectory: if(NOT TARGET TestB) add_subdirectory(TestB) endif() That should work. Andreas Awesome, that seems to do the trick. Thanks! David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.8-2882-ge023ee9
:
typedef std::vectorcmLocalGenerator* GeneratorVector;
// for a project collect all its targets by following depend
diff --git a/Source/cmGlobalUnixMakefileGenerator3.cxx
b/Source/cmGlobalUnixMakefileGenerator3.cxx
index e63de9c..ebd8219 100644
--- a/Source/cmGlobalUnixMakefileGenerator3.cxx
+++ b/Source/cmGlobalUnixMakefileGenerator3.cxx
@@ -103,18 +103,6 @@ cmGlobalUnixMakefileGenerator3
}
}
-//
-std::string EscapeJSON(const std::string s) {
- std::string result;
- for (std::string::size_type i = 0; i s.size(); ++i) {
-if (s[i] == '' || s[i] == '\\') {
- result += '\\';
-}
-result += s[i];
- }
- return result;
-}
-
void cmGlobalUnixMakefileGenerator3::Generate()
{
// first do superclass method
@@ -179,11 +167,14 @@ void cmGlobalUnixMakefileGenerator3::AddCXXCompileCommand(
*this-CommandDatabase , std::endl;
}
*this-CommandDatabase { std::endl
- \directory\: \ EscapeJSON(workingDirectory) \,
+ \directory\: \
+ cmGlobalGenerator::EscapeJSON(workingDirectory) \,
std::endl
- \command\: \ EscapeJSON(compileCommand) \,
+ \command\: \
+ cmGlobalGenerator::EscapeJSON(compileCommand) \,
std::endl
- \file\: \ EscapeJSON(sourceFile) \
+ \file\: \
+ cmGlobalGenerator::EscapeJSON(sourceFile) \
std::endl };
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e839a0ec481b83199f86407e51e27ac41461b582
commit e839a0ec481b83199f86407e51e27ac41461b582
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Thu May 17 00:01:03 2012 -0400
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu May 17 14:40:04 2012 +0200
CMake Nightly Date Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index a8c6e04..bb1005c 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
SET(CMake_VERSION_MAJOR 2)
SET(CMake_VERSION_MINOR 8)
SET(CMake_VERSION_PATCH 8)
-SET(CMake_VERSION_TWEAK 20120516)
+SET(CMake_VERSION_TWEAK 20120517)
#SET(CMake_VERSION_RC 1)
---
Summary of changes:
Modules/CMakeGenericSystem.cmake |6
Source/CMakeVersion.cmake |2 +-
Source/cmGlobalGenerator.cxx | 13 +
Source/cmGlobalGenerator.h|2 +
Source/cmGlobalNinjaGenerator.cxx | 42 +
Source/cmGlobalNinjaGenerator.h |6
Source/cmGlobalUnixMakefileGenerator3.cxx | 21 --
Source/cmNinjaTargetGenerator.cxx | 30
Tests/CMakeLib/run_compile_commands.cxx |2 +-
Tests/CMakeLists.txt |2 +-
10 files changed, 108 insertions(+), 18 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-157-g8519085
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 851908580307f4e45976eaef562ecf00f4025e28 (commit) via 3d10f65e39790863d8a939b9ea42c9680549a8ae (commit) from 3e0580ba6536186772203f09091ef960a9704c19 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=851908580307f4e45976eaef562ecf00f4025e28 commit 851908580307f4e45976eaef562ecf00f4025e28 Merge: 3e0580b 3d10f65 Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 14:58:20 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 14:58:20 2012 -0400 Merge topic 'CPack-preserveTimestampInSourcePackage' 3d10f65 CPack - preserve timestamp for CPACK_INSTALLED_DIRECTORIES. fixes: #0013193 --- Summary of changes: Source/CPack/cmCPackGenerator.cxx |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-160-gc47f904
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via c47f90487413703a1306cc0a0f03c05b981c2c2a (commit) via 92cee7626c5066a4af4cf66f85b0cd2c06bd9439 (commit) via 3bd41f2eb564d891c95e3ead5e72656b7daa3ff1 (commit) from 851908580307f4e45976eaef562ecf00f4025e28 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c47f90487413703a1306cc0a0f03c05b981c2c2a commit c47f90487413703a1306cc0a0f03c05b981c2c2a Merge: 8519085 92cee76 Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 14:58:31 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 14:58:31 2012 -0400 Merge topic 'ninja_convenience_targets' 92cee76 Ninja: Add a convenient 'help' target. 3bd41f2 Ninja: Add a convenient 'clean' target. --- Summary of changes: Source/cmGlobalNinjaGenerator.cxx | 42 + Source/cmGlobalNinjaGenerator.h |2 + 2 files changed, 44 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-180-g8e9101a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 8e9101a0cb81374a619686ee820c86d0531d6372 (commit)
via c806b23cfe08259efed1ed310613f65c16a60680 (commit)
via 761d93129fb72d0418facb785776533b33d24a01 (commit)
via 5b69ce49d4d80207d8fc90fe970875b4e545c13a (commit)
via 1b418f1fbfdeea561cc175929ac677d93e523e41 (commit)
via b0c07a13d1ee034875c2067f35bd39a9ffef7954 (commit)
via 0a169e628bb222fec7deead87f6ebe8fa77c7805 (commit)
via a7abf5e090379a77f50ce2285ac4c1c99159d9d2 (commit)
via 220afcaf842b9df501b4235df841395878c971e8 (commit)
via 62f6bce7a543a38965bfc2596afcd559e9fb7ee9 (commit)
via f5c5db0753161726c6032178bb10eb41b1ddde02 (commit)
via 7955e995ec400fb063529064b6232ca0eedfe5e0 (commit)
via a86cd33cdd497acdb6b77a44c146a9779730675e (commit)
via 319eeb0247f51bb2d380261ce7d63c7ce5020ed0 (commit)
via 72210c266238607e12c12ed7e983efed557fa784 (commit)
via dd07161c512e8d520da51f8bb82a65ec29aa57ba (commit)
via e6412e084ed6ba77c17292e3e7c5b9d8e2450bab (commit)
from 8f635d0268be899286669f1a8be5da6c97671470 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e9101a0cb81374a619686ee820c86d0531d6372
commit 8e9101a0cb81374a619686ee820c86d0531d6372
Merge: 8f635d0 c806b23
Author: David Cole david.c...@kitware.com
AuthorDate: Thu May 17 14:58:54 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu May 17 14:58:54 2012 -0400
Merge topic 'mumps_coverage'
c806b23 CDash now supports lots of files in coverage. So, show all files.
761d931 Do not try to run bullseye coverage if COVFILE env is empty.
5b69ce4 Update test data to match new coverage format.
1b418f1 Change GT.M Coverage Parser global
b0c07a1 Disable bullseye coverage for mumps coverage test.
0a169e6 Remove uncovered files from cache coverage data.
a7abf5e Add ability to specify more than one package directory or coverage
directory.
220afca Use TARGET_FILE expression to run ctest so it works with Xcode
and VS IDE.
62f6bce Use a script to run the test because WORKING_DIRECTORY is not in
2.8.2.
f5c5db0 Fix some warnings and a bug where it went past the length of a
vector.
7955e99 Add support for Cache coverage.
a86cd33 Add virutal destructor to silence warning.
319eeb0 Add test for mumps coverage. Also refactor code to prepare for
cache coverage.
72210c2 Fix line length.
dd07161 Fix warning about char* instead of const char*.
e6412e0 Add support to ctest for GTM mumps coverage.
diff --cc Source/CTest/cmCTestCoverageHandler.cxx
index 15c02b4,bb39e0d..81d3669
--- a/Source/CTest/cmCTestCoverageHandler.cxx
+++ b/Source/CTest/cmCTestCoverageHandler.cxx
@@@ -751,34 -761,47 +761,74 @@@ int cmCTestCoverageHandler::HandlePHPCo
}
return static_castint(cont-TotalCoverage.size());
}
+ //--
+ int cmCTestCoverageHandler::HandleMumpsCoverage(
+ cmCTestCoverageHandlerContainer* cont)
+ {
+ // try gtm coverage
+ cmParseGTMCoverage cov(*cont, this-CTest);
+ std::string coverageFile = this-CTest-GetBinaryDir() +
+ /gtm_coverage.mcov;
+ if(cmSystemTools::FileExists(coverageFile.c_str()))
+ {
+ cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT,
+Parsing Cache Coverage: coverageFile
+ std::endl);
+ cov.ReadCoverageFile(coverageFile.c_str());
+ return static_castint(cont-TotalCoverage.size());
+ }
+ else
+ {
+ cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT,
+ Cannot find foobar GTM coverage file: coverageFile
+ std::endl);
+ }
+ cmParseCacheCoverage ccov(*cont, this-CTest);
+ coverageFile = this-CTest-GetBinaryDir() +
+ /cache_coverage.cmcov;
+ if(cmSystemTools::FileExists(coverageFile.c_str()))
+ {
+ cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT,
+Parsing Cache Coverage: coverageFile
+ std::endl);
+ ccov.ReadCoverageFile(coverageFile.c_str());
+ }
+ else
+ {
+ cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT,
+ Cannot find Cache coverage file: coverageFile
+ std::endl);
+ }
+ return static_castint(cont-TotalCoverage.size());
+ }
+struct cmCTestCoverageHandlerLocale
+{
+ cmCTestCoverageHandlerLocale()
+{
+if(const char* l = cmSystemTools::GetEnv(LC_ALL))
+ {
+ lc_all = l;
+ }
+if(lc_all != C)
+ {
+
[Cmake-commits] CMake branch, master, updated. v2.8.8-182-gd6ec477
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via d6ec477b520d8c666811af0c4dc12bbae5519087 (commit) via b1d7c4b1d241445da31482ad893ec992bdccdabf (commit) from 8e9101a0cb81374a619686ee820c86d0531d6372 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d6ec477b520d8c666811af0c4dc12bbae5519087 commit d6ec477b520d8c666811af0c4dc12bbae5519087 Merge: 8e9101a b1d7c4b Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 14:59:07 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 14:59:07 2012 -0400 Merge topic 'FeatureSummaryNicerFormatting' b1d7c4b FeatureSummary.cmake: nicer formatting --- Summary of changes: Modules/FeatureSummary.cmake |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-184-g0c03cba
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 0c03cbabc4a5627eebc1d519e36f974a514c9d9c (commit) via d59ba0c591c58f0fe11aa72635680ec72ab12c6c (commit) from d6ec477b520d8c666811af0c4dc12bbae5519087 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c03cbabc4a5627eebc1d519e36f974a514c9d9c commit 0c03cbabc4a5627eebc1d519e36f974a514c9d9c Merge: d6ec477 d59ba0c Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 14:59:17 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 14:59:17 2012 -0400 Merge topic 'xcode-storyboard-files' d59ba0c Xcode: Recognize storyboard source files (#13214) --- Summary of changes: Source/cmGlobalXCodeGenerator.cxx |4 1 files changed, 4 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-188-ge1c5691
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via e1c5691a0facad84a54f651b3755322449251a0a (commit) via b3b095a933d7f355fcdd57c041c771b7618c9717 (commit) from 3e595b9ee597cde73c001bfa2947eef619fdaa95 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1c5691a0facad84a54f651b3755322449251a0a commit e1c5691a0facad84a54f651b3755322449251a0a Merge: 3e595b9 b3b095a Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 14:59:39 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 14:59:39 2012 -0400 Merge topic 'cmake-trace-elseif' b3b095a Print any evaluated 'elseif'/'else' commands in trace mode (#13220) --- Summary of changes: Source/cmIfCommand.cxx | 13 + Source/cmMakefile.cxx | 30 ++ Source/cmMakefile.h|5 + 3 files changed, 36 insertions(+), 12 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-190-g7873311
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 78733119cbec888f6e6614e9f204194d060be309 (commit) via d807aab28fd86586e8ecb5e4f4d35b43bc68d5f8 (commit) from e1c5691a0facad84a54f651b3755322449251a0a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78733119cbec888f6e6614e9f204194d060be309 commit 78733119cbec888f6e6614e9f204194d060be309 Merge: e1c5691 d807aab Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 14:59:52 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 14:59:52 2012 -0400 Merge topic 'ninja-issue-13069' d807aab Ninja: apply CMAKE_LANG_FLAGS_TYPE to executable targets (#13069) --- Summary of changes: Source/cmLocalGenerator.cxx |5 + Source/cmNinjaNormalTargetGenerator.cxx | 11 ++- 2 files changed, 7 insertions(+), 9 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-192-g8e9929d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 8e9929d527bf6f9dc607d9036e53d226bb165d32 (commit) via b94514f02018d566abc0156d5a729ebe9ee49105 (commit) from 78733119cbec888f6e6614e9f204194d060be309 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e9929d527bf6f9dc607d9036e53d226bb165d32 commit 8e9929d527bf6f9dc607d9036e53d226bb165d32 Merge: 7873311 b94514f Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 15:00:01 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu May 17 15:00:01 2012 -0400 Merge topic 'ninja-error-failbit' b94514f Ninja: mark rules/build file streams failed if error occurred (#13067, #13105) --- Summary of changes: Source/cmGlobalNinjaGenerator.cxx |5 + 1 files changed, 5 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.8-2894-g209ad9c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 209ad9c32a8d035f5ee512ac7c6649f4576f3138 (commit) via 8e9929d527bf6f9dc607d9036e53d226bb165d32 (commit) via 78733119cbec888f6e6614e9f204194d060be309 (commit) via e1c5691a0facad84a54f651b3755322449251a0a (commit) via 3e595b9ee597cde73c001bfa2947eef619fdaa95 (commit) via 0c03cbabc4a5627eebc1d519e36f974a514c9d9c (commit) via d6ec477b520d8c666811af0c4dc12bbae5519087 (commit) via 8e9101a0cb81374a619686ee820c86d0531d6372 (commit) via 8f635d0268be899286669f1a8be5da6c97671470 (commit) via c47f90487413703a1306cc0a0f03c05b981c2c2a (commit) via 851908580307f4e45976eaef562ecf00f4025e28 (commit) via 3e0580ba6536186772203f09091ef960a9704c19 (commit) from e023ee9117fd5e90b23bbe0e998ace04577ce5f1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=209ad9c32a8d035f5ee512ac7c6649f4576f3138 commit 209ad9c32a8d035f5ee512ac7c6649f4576f3138 Merge: e023ee9 8e9929d Author: David Cole david.c...@kitware.com AuthorDate: Thu May 17 15:00:41 2012 -0400 Commit: David Cole david.c...@kitware.com CommitDate: Thu May 17 15:00:41 2012 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.8-193-gcb37cae
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via cb37cae6918782d5bef6d30c30bee033de000372 (commit) from 8e9929d527bf6f9dc607d9036e53d226bb165d32 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb37cae6918782d5bef6d30c30bee033de000372 commit cb37cae6918782d5bef6d30c30bee033de000372 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri May 18 00:01:04 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri May 18 00:01:04 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index bb1005c..4518032 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ SET(CMake_VERSION_MAJOR 2) SET(CMake_VERSION_MINOR 8) SET(CMake_VERSION_PATCH 8) -SET(CMake_VERSION_TWEAK 20120517) +SET(CMake_VERSION_TWEAK 20120518) #SET(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
