Re: [cmake-developers] Severe regression caused by #14972 fixes
This will not be done before the freeze for 3.1 on Thursday. Reverting 7243c951 will resolve the problem for ReactOS in out-of-source builds. So, we either revert that or hope Ninja can be fixed to deal with the large dependency lists w/out crashing. In the discussion with Adam, he mentioned (about input files) that CMake can not know that some file will always exist or not, and that it doesn't know files is generated unless someone tells that, *unfortunately some projects don't* Reverting this change makes more sense, because CMake has always been advertised as being designed for out-of-source builds, and we cannot penalize every single sane CMake user out there simply because some projects do not properly mark their generated input files (in custom commands) as GENERATED. I don't understand why is it okay for the CMake project (at least in ReactOS case) to introduce now a (very) huge list of our codebase *source files* (files that exist in our *repo* and not *generated* nor we can even *assume* they may not exist at some point, because they will *always* exist) simply to solve a problem that is, if some projects do *not* properly use CMake (GENERATED property, adding dependencies properly on commands/target that generate the said input files...etc) we need to do this to keep them working. The extra bloat of generating a very large list of phony rules on *source* files to solve a CMake misuse problem suggests that we're Doing It Wrong. If ninja didn't crash on us, we would probably never find out about this bloat, unless some of us randomly had the idea of diffing the old build log (from CMake 2.8.x) with this new one. -- 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] New command 'file(LOCK_DIRECTORY ...)'
On 07-Oct-14 16:25, Brad King wrote:
On 10/07/2014 02:49 AM, Ruslan Baratov wrote:
How it will looks like in terms of CMake code?
That's what I'm asking you to think through and propose ;)
Thanks,
-Brad
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock
* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process
Ruslo
--
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] New command 'file(LOCK_DIRECTORY ...)'
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it. Perhaps the
code is starting a daemon and passes off responsibility for the
unlock side to the daemon process.
* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock
Yes. We also need the locking API to return information about
whether we really acquired the lock.
* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process
I think all we need there is a way to ask CMake to take over
responsibility for a lock that it did not originally create.
It can also be in the file() command.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe regression caused by #14972 fixes
On 10/08/2014 03:45 AM, Amine Khaldi wrote: Reverting this change makes more sense This is the simplest solution for the upcoming 3.1 release because it just restores behavior to what 3.0 does. I've done it here: Ninja: Limit custom command side-effects to build folder http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de8e534b simply to solve a problem that is, if some projects do *not* properly use CMake (GENERATED property, adding dependencies properly on commands/target that generate the said input files...etc) we need to do this to keep them working. This is not about supporting projects that do it wrong. Ninja wants to know not just that a file is generated, but also *which* custom command generates it. We have no interface for specifying side-effect outputs whose timestamps do not need to be newer than the inputs. That is what this issue is about: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 The reason is that CMake was designed long before Ninja existed, and all the other build systems not only do not need this information, but have no place to put it even if we did have it. See also my reply to Adam's sibling message to yours. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe regression caused by #14972 fixes
On 10/07/2014 04:53 PM, Adam Strzelecki wrote: In meantime I've pushed stage/cmp0055-disable-ninja-side-effects that make CMake warn about this compatibility layer when such phony rules are about to be emitted. What I've been trying to say is that this is NOT about compatibility with broken projects. It is a *fundamental limitation* of the current CMake custom command specification interface (add_custom_command). If you start requiring explicit specification of side-effects as custom command outputs, you will make it *impossible* for project code to specify their build rules for cases involving side-effect outputs whose timestamps do not need to be newer than their inputs. Non-Ninja build systems do *not* support this. This issue: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 documents a few such cases. It explains that we need a new interface, perhaps as an option to add_custom_command, to specify side-effect outputs of rules. Another possible middle-ground workaround is to generate phony rules only for custom command dependencies that are marked with the GENERATED property. That would avoid the phony rule bloat and simply require projects to explicitly mark their generated side effects. We still won't be able to tell Ninja which rule generates them, but at least we could reduce the number of phony rules. However, there is no way this will be done for 3.1 by tomorrow, so it would be best to think about a full solution to #14963 to start development now and target the 3.2 release. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe regression caused by #14972 fixes
This is the simplest solution for the upcoming 3.1 release because it just restores behavior to what 3.0 does. I've done it here: Okay. But still I feel like this is just workaround rather than solution for the problem. This is not about supporting projects that do it wrong. Ninja wants to know not just that a file is generated, but also *which* custom command generates it. We have no interface for specifying side-effect outputs whose timestamps do not need to be newer than the inputs. Yes, it isn't about doing anything wrong, but to make projects building fine with Make build fine with Ninja too. And you are right here, we have no means for provide proper transition to remove this implicit compatibility layer. We lack OUTPUT for add_custom_target. I can work on OUTPUT support for add_custom_target if you want? Together with new POLICY it will make sense, unless you have other opinion on that. But I guess it won't make it to 3.1? That is what this issue is about: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 Shouldn't it be called Add explicit specification of custom TARGET side effect outputs? --Adam -- 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] explicit custom command side-effects (was: Severe regression caused by #14972 fixes)
On 10/08/2014 09:55 AM, Adam Strzelecki wrote:
We lack OUTPUT for add_custom_target.
I can work on OUTPUT support for add_custom_target if you want?
This is not just about add_custom_target, and it is not about OUTPUT.
Custom targets have no explicit output by design, but they can have
DEPENDS on custom commands that have outputs.
Both add_custom_target and add_custom_command can run operations that
produce side-effects. Both commands need a way to specify any side
effects they produce. Perhaps a new option like GENERATES can be
added for this. For example:
add_custom_target(Provider
COMMAND some-generator -o side-effect
GENERATES side-effect
)
or:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/generator-stamp.txt
COMMAND some-generator -o side-effect
COMMAND ${CMAKE_COMMAND} -E touch generator-stamp.txt
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/generator-input.txt
GENERATES side-effect
)
The GENERATES value(s) would be marked with the GENERATED property.
For Ninja we would add extra outputs to the generated rule and
ask Ninja to restat them to avoid the always-rebuild case. For
other generators no additional build system content is needed.
Together with new POLICY it will make sense, unless you have other
opinion on that.
We need some kind of transition plan that may or may not be a policy.
Let's get the design of the new interface done first.
But I guess it won't make it to 3.1?
Absolutely not for 3.1. The feature freeze for it is upon us NOW
and we haven't even started the design for the new behavior yet.
We have plenty of time before 3.2 though to get it right.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindThreads_overhaul topic
On 10/07/2014 12:18 PM, Rolf Eike Beer wrote: + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) Both issues should be fixed now. Thanks. Your use of an interface target for this is a clever way of abstracting the differences between libraries and flags. Nice. I'd rather reserve the CMake:: imported target namespace for future use. The convention in other Find modules is to prefix the imported targets with the name of the package. In this case we have no good name for the library within the namespace. Here is a brainstorming list of possible names: Threads::Threads Threads::Interface # my favorite Threads::Native Threads::System Please pick one of these or propose your own and update the topic. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
- Original Message -
- Original Message -
On 10/06/2014 10:36 AM, Adam Strzelecki wrote:
Sure, I think it would be good to require 10.6.
Moreover I believe nobody nowadays builds for 10.5 on 10.5.
Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.
Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either
disabling rpath altogether on 10.5 or changing the new hunk:
+ foreach(rpath ${${ikey}_RPATHS})
+set(changes ${changes} -delete_rpath ${rpath})
+ endforeach()
to warn and skip removal when hosted on 10.5. Or another option you
find.
This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.
Thanks,
-Brad
I don't have a 10.5 machine, but I've put in a commit which I hope solves the
problem.
36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater.
I pushed more fixes for this. Instead of requiring 10.6, I took the other path
of warning when rpaths need changed at install time and skip it.
This should also fix the CMP0042 test which started failing.
By the way, Brad, your change to require 10.6 for the BundleUtilities test is
no longer required on the rpath-osx-10_6 topic.
However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic.
Clint
--
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] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/08/2014 11:05 AM, clin...@elemtech.com wrote: I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing. Thanks. The message is currently: + msg WARNING: Target \ this-Target-GetName() + \ has runtime paths which cannot be changed during install. + To change runtime paths, OS X version 10.6 or newer is required. + Therefore, runtime paths will not be changed when installing.; + cmSystemTools::Message(msg.str().c_str(), Warning); Can that be changed to an IssueMessage, possibly on a cmMakefile for at least a little context? Also it should suggest using CMAKE_BUILD_WITH_INSTALL_RPATH. By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic. I thought it was a missing piece of your original change. Since you've reverted that I've now reverted mine so we'll see how testing goes. However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic. I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to make local testing of both together easier. Please base the above-requested fixes on: OSX: Warn when attempting to change runtime paths on OS X 10.5 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindThreads_overhaul topic
Am Mittwoch, 8. Oktober 2014, 10:54:12 schrieb Brad King: On 10/07/2014 12:18 PM, Rolf Eike Beer wrote: + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) Both issues should be fixed now. Thanks. Your use of an interface target for this is a clever way of abstracting the differences between libraries and flags. Nice. All credits go to Timo Rothenpieler, I just refactored his changes and pushed this upstream. I'd rather reserve the CMake:: imported target namespace for future use. The convention in other Find modules is to prefix the imported targets with the name of the package. In this case we have no good name for the library within the namespace. Here is a brainstorming list of possible names: Threads::Threads Threads::Interface # my favorite Threads::Native Threads::System Please pick one of these or propose your own and update the topic. I'm not sure about Threads::Interface, it sounds so generic or abstract to me, but this target offers no abstraction of the thread API. All others have different up- and downsides, so I think I'll stay with Threads::Threads, that is the one that probably results in the least blame for a badly chosen name. Eike signature.asc Description: This is a digitally signed message part. -- 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] FindThreads_overhaul topic
On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: All credits go to Timo Rothenpieler Okay. Please add a Co-Author: or Inspired-by: footer line to give this credit. I'm not sure about Threads::Interface, it sounds so generic or abstract to me, but this target offers no abstraction of the thread API. All others have different up- and downsides, so I think I'll stay with Threads::Threads, that is the one that probably results in the least blame for a badly chosen name. On second thought I agree Threads::Interface is too generic. It exposes an implementation detail in the name. I agree Threads::Threads is the best or now. I suspect other packages will encounter a similar double-name later. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindThreads_overhaul topic
Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King: On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: All credits go to Timo Rothenpieler Okay. Please add a Co-Author: or Inspired-by: footer line to give this credit. He is recorded as author of that change. Only the first and last of the 3 commits in that branch are authored by me, and recorded that way. I'm not sure about Threads::Interface, it sounds so generic or abstract to me, but this target offers no abstraction of the thread API. All others have different up- and downsides, so I think I'll stay with Threads::Threads, that is the one that probably results in the least blame for a badly chosen name. On second thought I agree Threads::Interface is too generic. It exposes an implementation detail in the name. I agree Threads::Threads is the best or now. I suspect other packages will encounter a similar double-name later. Will push an update soonish. signature.asc Description: This is a digitally signed message part. -- 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] fix-OSX-bundle-rpaths-and-Qt5 topic
On Wednesday, October 08, 2014 11:17:03 AM Brad King wrote: On 10/08/2014 11:05 AM, clin...@elemtech.com wrote: I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing. Thanks. The message is currently: + msg WARNING: Target \ this-Target-GetName() + \ has runtime paths which cannot be changed during install. + To change runtime paths, OS X version 10.6 or newer is required. + Therefore, runtime paths will not be changed when installing.; + cmSystemTools::Message(msg.str().c_str(), Warning); Can that be changed to an IssueMessage, possibly on a cmMakefile for at least a little context? Also it should suggest using CMAKE_BUILD_WITH_INSTALL_RPATH. Fixed. By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic. I thought it was a missing piece of your original change. Since you've reverted that I've now reverted mine so we'll see how testing goes. Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change rpaths. Clint -- 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] Any ideas for accessing the Dart source code?
On 2014-10-08 10:05-0400 Brad King wrote: On 10/07/2014 09:23 PM, Alan W. Irwin wrote: I have now looked at the documentation for ctest-3.0.2, and cdash is mentioned a lot more but then so is dart. I think that documentation should be updated to point users exclusively at cdash Help: Replace 'Dart' with 'CDash' in ctest.1 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8aa0cdf Thanks. That is a step in the right direction, but there are more mentions of dart then you have dealt with so far. See the results from ctest --help-full (at least for version 3.0.2). Furthermore, to prevent others being misled like I was by http://www.cmake.org/dart/HTML/Install.shtml, could someone with write access to that web server either drop that page or modify that page so that it at least mentions that dart is no longer maintained and cdash is the suggested alternative? I will look at that, thanks. -Brad __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] Any ideas for accessing the Dart source code?
On 10/08/2014 01:34 PM, Alan W. Irwin wrote: Thanks. That is a step in the right direction, but there are more mentions of dart then you have dealt with so far. See the results from ctest --help-full (at least for version 3.0.2). According to: $ git grep -i dart -- Help Modules the remaining mentions of Dart are in: * The FindDart module which we have to keep for compatibility. It is only linked from the list of available modules. * The Dart module which we have to keep for compatibility, and whose documentation says so and refers to the CTest module. * Discussion of the DartConfiguration.tcl configuration file, which is actually for configuring CTest (it's historical). There is no text left that suggests using Dart for anything in the ctest(1) manual. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forcing colorization of output from cmake
On Wed, 2014-10-08 at 12:55 -0400, Brad King wrote:
On 10/08/2014 12:15 PM, Paul Smith wrote:
Maybe we could add another valid value to --switch, like --switch=FORCE
which would always colorize.
[snip]
The best option seems to be to add another flag to the color bitflag
variable that forces colorization always.
Yes, I think both of the above make sense. If you want to work on
it please read CONTRIBUTING.rst from the top of our source tree
in Git ( http://cmake.org/cmake.git ) and come to the developers
list with a proposal:
Hi all. Attached please find a proposed patch for the above. I still
think there's some slightly awkward redundancy between AssumeTTY and the
new ForceTTY, but I'm not sure these can actually be combined into one
flag... certainly not without reworking more of how AssumeTTY is
interpreted and used than I felt confident with.
I didn't try to allow FORCE to be case-insensitive. It wouldn't be
hard, but I wasn't sure if it was worth it. You must capitalize it as
the code is written today. I found precedent for both options.
Also, the check for MAKE_TERMOUT might not be something you want to
keep... there's not a lot of precedent in the code, that I found, for
looking at other utilities' environment variables. On the other hand
it's darn handy to have this just work without having to export
COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
There's no GNU Makefiles generator, and I couldn't come up with a good
way to implement this in the generic Unix Makefiles generator.
From 82d2c63750c706e5f4f749a123934c725432 Mon Sep 17 00:00:00 2001
From: Paul Smith p...@mad-scientist.net
Date: Wed, 8 Oct 2014 14:18:14 -0400
Subject: [PATCH] cmake: Allow forced color output
Provide a new Terminal.h flag, Color_ForceTTY, which causes color output
always regardless of TTY/Console settings. If --switch=FORCE is given
on the cmake command line, enable this flag. Also check for the
MAKE_TERMOUT variable, set by GNU make 4.1+ when make is capturing
stdout which will eventually go to a terminal, and set Color_ForceTTY.
---
Source/cmSystemTools.cxx | 36 +---
Source/cmcmd.cxx | 8 +++-
Source/kwsys/Terminal.c| 8 +---
Source/kwsys/Terminal.h.in | 17 +++--
4 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index fbb4416..7c983c6 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2290,31 +2290,45 @@ std::string const cmSystemTools::GetCMakeRoot()
void cmSystemTools::MakefileColorEcho(int color, const char* message,
bool newline, bool enabled)
{
+ if(!enabled)
+{
+// Color is disabled. Print without color.
+fprintf(stdout, %s%s, message, newline? \n : );
+return;
+}
+
// On some platforms (an MSYS prompt) cmsysTerminal may not be able
// to determine whether the stream is displayed on a tty. In this
// case it assumes no unless we tell it otherwise. Since we want
// color messages to be displayed for users we will assume yes.
// However, we can test for some situations when the answer is most
- // likely no.
- int assumeTTY = cmsysTerminal_Color_AssumeTTY;
+ // likely no, and other cases where it should be forced to yes.
+ int flags = cmsysTerminal_Color_AssumeTTY;
+
if(cmSystemTools::GetEnv(DART_TEST_FROM_DART) ||
cmSystemTools::GetEnv(DASHBOARD_TEST_FROM_CTEST) ||
cmSystemTools::GetEnv(CTEST_INTERACTIVE_DEBUG_MODE))
{
// Avoid printing color escapes during dashboard builds.
-assumeTTY = 0;
-}
-
- if(enabled)
-{
-cmsysTerminal_cfprintf(color | assumeTTY, stdout, %s%s,
- message, newline? \n : );
+flags = 0;
}
else
{
-// Color is disabled. Print without color.
-fprintf(stdout, %s%s, message, newline? \n : );
+// Newer versions of GNU make (4.0+) have the ability to separate the
+// output of parallel builds so they don't interfere with each other.
+// However this means commands invoked by make don't appear to have a TTY.
+// GNU make 4.1+ exports an environment variable MAKE_TERMOUT which is
+// non-empty if make thinks that it is printing _it's_ output to stdout.
+// If this variable exists and is non-empty, then force color output.
+const char* var = cmSystemTools::GetEnv(MAKE_TERMOUT);
+if(var var[0] != '\0')
+ {
+ flags |= cmsysTerminal_Color_ForceTTY;
+ }
}
+
+ cmsysTerminal_cfprintf(color | flags, stdout, %s%s,
+ message, newline? \n : );
}
#endif
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index a0c67e0..af9b139 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -907,6 +907,7 @@ int cmcmd::ExecuteEchoColor(std::vectorstd::string args)
bool enabled = true;
int color = cmsysTerminal_Color_Normal;
+ int force = 0;
bool
Re: [cmake-developers] FindThreads_overhaul topic
As an aside have we formally documented that we are reserving the CMake namespace on imported targets anywhere? On Wed, Oct 8, 2014 at 11:48 AM, Rolf Eike Beer e...@sf-mail.de wrote: Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King: On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: All credits go to Timo Rothenpieler Okay. Please add a Co-Author: or Inspired-by: footer line to give this credit. He is recorded as author of that change. Only the first and last of the 3 commits in that branch are authored by me, and recorded that way. I'm not sure about Threads::Interface, it sounds so generic or abstract to me, but this target offers no abstraction of the thread API. All others have different up- and downsides, so I think I'll stay with Threads::Threads, that is the one that probably results in the least blame for a badly chosen name. On second thought I agree Threads::Interface is too generic. It exposes an implementation detail in the name. I agree Threads::Threads is the best or now. I suspect other packages will encounter a similar double-name later. Will push an update soonish. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
