Re: [cmake-developers] Listing source-tree files encountered
On 07/21/2015 11:57 AM, Clifford Yapp wrote: The attached patch seems to work - Brad, should I submit this to the issue tracker? If it needs any more tweaking let me know. No issue tracker entry needed. CONTRIBUTING.rst explains that the mailing list is preferred. I'll take a look at this when I get a chance. Looking at the target properties test, should there also be a test for the SOURCES property? The SOURCE_DIR property in particular is intended to work with the current behavior (relative path lists unless original target specifier is a full path) from SOURCES, so IMHO it might be a good idea to put a test in for that as well... There is some coverage of the SOURCES property in other tests but having a dedicated check for it would be worthwhile too. 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] Listing source-tree files encountered
On Mon, Jul 20, 2015 at 4:42 PM, Ben Boeckel ben.boec...@kitware.com wrote:
For testing these properties, what would you suggest? They're
intended to report local configure-time absolute paths, which can't be
hard coded... is it enough to check them to make sure they're not
empty or is there something more robust that could be devised?
They should end with the path under the CMake source tree at least (I
assume they are absolute?). Try matching this regex:
.*/Testing/RunCMake/get_property
possibly? You can also put the test under an add_subdirectory() call as
well.
The attached patch seems to work - Brad, should I submit this to the
issue tracker? If it needs any more tweaking let me know.
Looking at the target properties test, should there also be a test for
the SOURCES property? The SOURCE_DIR property in particular is
intended to work with the current behavior (relative path lists unless
original target specifier is a full path) from SOURCES, so IMHO it
might be a good idea to put a test in for that as well...
Cheers,
CY
diff --git a/Help/manual/cmake-properties.7.rst
b/Help/manual/cmake-properties.7.rst
index 1d27a64..ac893c2 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -114,6 +114,7 @@ Properties on Targets
/prop_tgt/AUTOUIC_OPTIONS
/prop_tgt/AUTORCC
/prop_tgt/AUTORCC_OPTIONS
+ /prop_tgt/BINARY_DIR
/prop_tgt/BUILD_WITH_INSTALL_RPATH
/prop_tgt/BUNDLE_EXTENSION
/prop_tgt/BUNDLE
@@ -244,6 +245,7 @@ Properties on Targets
/prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG
/prop_tgt/RUNTIME_OUTPUT_NAME
/prop_tgt/SKIP_BUILD_RPATH
+ /prop_tgt/SOURCE_DIR
/prop_tgt/SOURCES
/prop_tgt/SOVERSION
/prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG
diff --git a/Help/prop_tgt/BINARY_DIR.rst b/Help/prop_tgt/BINARY_DIR.rst
new file mode 100644
index 000..a6c1c12
--- /dev/null
+++ b/Help/prop_tgt/BINARY_DIR.rst
@@ -0,0 +1,4 @@
+BINARY_DIR
+--
+
+Reports the value of CMAKE_CURRENT_BINARY_DIR in the directory in which the
target was defined.
diff --git a/Help/prop_tgt/SOURCE_DIR.rst b/Help/prop_tgt/SOURCE_DIR.rst
new file mode 100644
index 000..de93f29
--- /dev/null
+++ b/Help/prop_tgt/SOURCE_DIR.rst
@@ -0,0 +1,4 @@
+SOURCE_DIR
+--
+
+Reports the value of CMAKE_CURRENT_SOURCE_DIR in the directory in which the
target was defined.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 0303f1e..ff4f161 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2959,6 +2959,8 @@ const char *cmTarget::GetProperty(const std::string prop,
MAKE_STATIC_PROP(COMPILE_DEFINITIONS);
MAKE_STATIC_PROP(IMPORTED);
MAKE_STATIC_PROP(NAME);
+ MAKE_STATIC_PROP(BINARY_DIR);
+ MAKE_STATIC_PROP(SOURCE_DIR);
MAKE_STATIC_PROP(SOURCES);
#undef MAKE_STATIC_PROP
if(specialProps.empty())
@@ -2971,6 +2973,8 @@ const char *cmTarget::GetProperty(const std::string prop,
specialProps.insert(propCOMPILE_DEFINITIONS);
specialProps.insert(propIMPORTED);
specialProps.insert(propNAME);
+specialProps.insert(propBINARY_DIR);
+specialProps.insert(propSOURCE_DIR);
specialProps.insert(propSOURCES);
}
if(specialProps.count(prop))
@@ -3053,6 +3057,14 @@ const char *cmTarget::GetProperty(const std::string
prop,
{
return this-GetName().c_str();
}
+else if (prop == propBINARY_DIR)
+ {
+ return this-GetMakefile()-GetCurrentBinaryDirectory();
+ }
+else if (prop == propSOURCE_DIR)
+ {
+ return this-GetMakefile()-GetCurrentSourceDirectory();
+ }
else if(prop == propSOURCES)
{
if (this-Internal-SourceEntries.empty())
diff --git a/Tests/RunCMake/get_property/target_properties-stderr.txt
b/Tests/RunCMake/get_property/target_properties-stderr.txt
index d0981ac..8a06b38 100644
--- a/Tests/RunCMake/get_property/target_properties-stderr.txt
+++ b/Tests/RunCMake/get_property/target_properties-stderr.txt
@@ -3,4 +3,9 @@ get_property:
get_target_property: --value--
get_property: --value--
get_target_property: --gtp_val-NOTFOUND--
-get_property: $
+get_property:
+get_target_property: --(.*)Tests/RunCMake/get_property--
+get_property: --(.*)Tests/RunCMake/get_property--
+get_target_property:
--(.*)Tests/RunCMake/get_property/target_properties-build--
+get_property: --(.*)Tests/RunCMake/get_property/target_properties-build--$
+
diff --git a/Tests/RunCMake/get_property/target_properties.cmake
b/Tests/RunCMake/get_property/target_properties.cmake
index c5a141d..9ff833a 100644
--- a/Tests/RunCMake/get_property/target_properties.cmake
+++ b/Tests/RunCMake/get_property/target_properties.cmake
@@ -14,3 +14,5 @@ set_target_properties(tgt PROPERTIES empty custom value)
check_target_property(tgt empty)
check_target_property(tgt custom)
check_target_property(tgt noexist)
+check_target_property(tgt SOURCE_DIR)
+check_target_property(tgt BINARY_DIR)
--
Powered by www.kitware.com
Please keep messages on-topic and
[cmake-developers] [CMake 0015658]: Allow generator expressions in add_custom_command (and add_custom_target)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15658 == Reported By:Ben Boeckel Assigned To: == Project:CMake Issue ID: 15658 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new Target Version: CMake 3.4 == Date Submitted: 2015-07-21 11:19 EDT Last Modified: 2015-07-21 11:19 EDT == Summary:Allow generator expressions in add_custom_command (and add_custom_target) Description: Now that LOCATION is disallowed, using a target path as an argument to a custom command is not possible without warnings (or making CMP0026 OLD). At least OUTPUT, COMMAND, MAIN_DEPENDENCY, DEPENDS, WORKING_DIRECTORY, and SOURCES (for a_c_t) should expand generator expressions. Some may already do so via properties being genex-expanded already (just WORKING_DIRECTORY IIRC). == Issue History Date ModifiedUsername FieldChange == 2015-07-21 11:19 Ben BoeckelNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator expressions for archive|library|runtime output directory
On Tue, Jul 21, 2015 at 10:03:42 -0400, Brad King wrote:
Okay. I've made a note about this issue to make sure it is fixed before 3.4.
Meanwhile I have another comment on genex support in the OUTPUT_DIRECTORY
properties. Currently the properties support both
{ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY
and
{ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY_CONFIG
variants. When the former is used CMake will still add the /CONFIG
directory suffix to the end of the value. When the latter is used
CMake does not do this.
With the former, when a genex like $CONFIG is used, it is likely
that the user does not want CMake to add the /CONFIG suffix.
Perhaps we should detect when a genex is present in the value and
skip adding the suffix, thus trusting the user to have done the right
thing (e.g. $1:value will still not get a suffix).
+1
The main use case I've come across is when generating modules for
languages using CMake. Generally, there you want:
${common_output_path}/$CONFIG/path/to/module.so
since the interpreter searches using the last path parts from the module
import (here, 'path.to.module').
The only way to reliable do it right is to iterate over
CMAKE_CONFIGURATION_TYPES and set the properties that way with
${CMAKE_CFGINT_DIR}.
Of course this would have to be documented carefully. We could also
disallow a genex in the latter (per-config) variants to encourage
modern use of the former.
+1
--Ben
--
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] Capturing messages to log files
On Mon, Jul 20, 2015 at 9:36 AM, Brad King brad.k...@kitware.com wrote: On 07/18/2015 03:45 PM, Clifford Yapp wrote: Am I correct that cmSystemTools::Message is the gateway through which all of the console output from CMake exits? If so, perhaps the simplest thing to do is simply allow copying to a log file at that point? It would be nice to have files containing only errors, only warnings, etc. but it's not immediately clear to me how to set something like that up... Look at Source/QtDialog/QCMake.cxx for use of SetStdoutCallback, SetStderrCallback, SetMessageCallback, and SetProgressCallback. The cmake-gui uses those to capture everything for display in the dialog. -Brad Ah - thanks for the pointer. Working on understanding how the various overrides work - cmakemainProgressCallback et. al. and how Qt is handling the various bits. Cheers, CY -- 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] A policy for Policies
On 07/01/2015 02:17 PM, Stephen Kelly wrote: Brad King wrote: We need to provide such capabilities so authors that do maintain their projects can be confident they've ported away from behavior that will later become an error. Makes sense to me. I see topic end-Policy-lifetime with commit range e7fbd489..c7512801 currently in 'next', but it doesn't have anything about making things into errors early. I thought we agreed to build that infrastructure first. I guess POLICY_WARNING and POLICY_OPTIONAL_WARNING are a step in that direction but I'd like to see the actual error options be available before we start showing the warnings unconditionally. I think the warning should indicate which version of CMake introduced the policy (already the case) and the date that was released. This might provide the information needed to prioritize that Alex was looking for by instead asking for the date it would become an error. The problem with such dates is when the policy is introduced we don't know the date of the next release. Even if we had some kind of lookup table maintained as releases are made, the wording of policy messages would then change as a release is made, which is not great for testing. Let's skip these for 3.4 and see how the warnings for the 14 policies in the above and below groups work out. The reason I suggested emitting these unconditional warnings is that we should establish what the lifecycle of policies actually is. No. My view throughout the conversation in this thread is that we don't know an appropriate length for the lifecycle. We should start by assuming it is longer than some of the oldest policies (e.g. CMP0011) and working our way forward through time. That will let us see how projects handle steps of the lifecycle without aggressively warning even on recently valid code. The lifecycle proposed in commit d5b1839a is way too aggressive. The end-Policy-lifetime topic looks nothing like the schedule or selection of policies discussed in the last few messages of this thread. Setting a policy to OLD is not designed to be a convenience for the maintainer of the project, who can schedule appropriate handling of the policy. Originally it was intended to be exactly that. Not all projects are maintained on the same release schedule that CMake has. If they release only once per year then CMake could be deep into a policy lifecycle as proposed in d5b1839a. Many people skip a few CMake releases at a time and may jump over some of the steps. I think step 2 of that schedule should be at least 3 releases after step 1, but we don't really know yet what the schedule should be as mentioned above. All we've agreed upon in this thread is that 3.4 can emit unconditional warnings for CMP0011 and below and also CMP0024 and CMP0026 (since those are the ones we really want to get rid of and may be frequently set to OLD). Also it should come with options to make the warnings into errors so they are easier to find. -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] Listing source-tree files encountered
Clifford Yapp wrote: With David's patch and the above SOURCE_DIR property, it looks like the necessary pieces are now present for target + source processing. That might happen to work for brlcad, but it is not really true. CMake looks in the source dir for relative files listed in targets, then the binary dir, then it tries a number of language-specific extensions in each of the source and binary directories. And it does that at generate-time after evaluating generator expressions. And the file extensions it uses as candidates are determined by cmake variables that the user can modify. http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSourceFile.cxx;h=86f0a7a8;hb=HEAD#l138 So, your cmake function will fail on a target like add_executable(hello # main.cpp exists main # Exists in source dir foo.cpp # Exists in build dir generated_file.cpp # bar.c exists in source dir bar # another_generated_file.h exists in build dir another_generated_file # determined_at_generate_time.cpp exists in source dir $1:determined_at_generate_time ) Why not add a generator expression like $TARGET_SOURCES:tgt and use that instead? You can implement/define that as creating absolute paths. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
Brad King wrote: The lifecycle proposed in commit d5b1839a is way too aggressive. The end-Policy-lifetime topic looks nothing like the schedule or selection of policies discussed in the last few messages of this thread. Yes. The discussion died after my proposal. I've reverted the branch. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Listing source-tree files encountered
On 07/21/2015 02:50 PM, Stephen Kelly wrote: Clifford Yapp wrote: With David's patch and the above SOURCE_DIR property, it looks like the necessary pieces are now present for target + source processing. That might happen to work for brlcad, but it is not really true. The goal here is to get rid of BRL-CAD's need for overriding commands without necessarily solving all the problems in general so long as the changes are independently useful and not specific to BRL-CAD's needs. I think SOURCE_DIR and BINARY_DIR provide useful information, as will the TARGETS global property discussed in another branch of this thread. Why not add a generator expression like $TARGET_SOURCES:tgt and use that instead? You can implement/define that as creating absolute paths. I would welcome this more complete solution too. -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] CTest threshold exceeds 1024 bytes
Hi Brad, I've attached a patch which learns CTest to handle it. I hope this patch could be merged. Best Regards Roman -Ursprüngliche Nachricht- Von: Brad King [mailto:brad.k...@kitware.com] Gesendet: Dienstag, 21. Juli 2015 15:53 An: Roman Wüger Cc: CMake Developer MailingList; CMake MailingList Betreff: Re: [CMake] CTest threshold exceeds 1024 bytes On 07/21/2015 04:12 AM, Roman Wüger wrote: Is there a way to get the full output without modifying every CMake Script of about ~ 35 projects? CTest always truncates the output of passing tests unless the test output contains the literal text CTEST_FULL_OUTPUT. This was done long ago to limit the size of submissions of passed tests. CTest will have to be taught an option to skip this. Take a look at the definition and uses of CleanTestOutput in Source/CTest. There are already variables like CustomMaximumPassedTestOutputSize internally but it looks like there is no way to configure them at runtime. -Brad 0001-CTest-learned-to-limit-the-output-of-passed-and-fail.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015657]: cmTarget::GetOutputInfo called for mytarget which has type UTILITY (CMake Internal Error)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15657 == Reported By:Erik Sjölund Assigned To: == Project:CMake Issue ID: 15657 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-21 07:16 EDT Last Modified: 2015-07-21 07:16 EDT == Summary:cmTarget::GetOutputInfo called for mytarget which has type UTILITY (CMake Internal Error) Description: I was experimenting with exporting. I don't know if the content of the CMakeLists.txt makes sense but CMake told me to report a bug: CMake Internal Error (please report a bug) Here is the content of the CMakeLists.txt file: cmake_minimum_required(VERSION 3.3) add_custom_command(OUTPUT empty.txt COMMAND touch empty.txt) add_custom_target(mytarget DEPENDS empty.txt) export(TARGETS mytarget FILE export.cmake) Steps to Reproduce: The shell terminal session is attached as a file (terminal-output.txt). == Issue History Date ModifiedUsername FieldChange == 2015-07-21 07:16 Erik Sjölund New Issue 2015-07-21 07:16 Erik Sjölund File Added: terminal-output.txt == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] CTest threshold exceeds 1024 bytes
Hello, when I run CTest from the command line with the same parameters as on the build server, then everything is working fine. If I run the command on the build server then I get a message which says that the threshold of 1024 bytes are exceeded. The output are debug messages and not failures. I have the output on CDash and on Jenkins. Here is the command which I call: ctest -C Release --output-on-failure --no-compress-output -T test Is there a way to get the full output without modifying every CMake Script of about ~ 35 projects? Thanks in advance Best Regards Roman -- 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] install(EXCLUDE_FROM_ALL) new feature - request for comment
On 07/18/2015 02:03 PM, Stephen Kelly wrote:
I find the title interesting but I didn't attempt to read the email.
Please make a proposal instead of just dumping a tree of text
For reference, the text is from the issue tracker entry:
No way to exclude a component install() from a full installation
http://www.cmake.org/Bug/view.php?id=14921
It proposes a patch attached to that entry which I've also attached
here. The idea is to define install() rules which are *not* part of
the default installation when no component is specified. IIUC then
one would need to request the specific component explicitly during
installation in order to get it.
-Brad
diff --git a/Source/cmInstallCommand.cxx b/Source/cmInstallCommand.cxx
index 3c76bd6..23943c3 100644
--- a/Source/cmInstallCommand.cxx
+++ b/Source/cmInstallCommand.cxx
@@ -31,7 +31,8 @@ static cmInstallTargetGenerator* CreateInstallTargetGenerator(cmTarget target,
impLib, args.GetPermissions().c_str(),
args.GetConfigurations(), args.GetComponent().c_str(),
message,
-args.GetOptional() || forceOpt);
+args.GetExcludeFromAll(),
+args.GetOptional() || forceOpt);
}
static cmInstallFilesGenerator* CreateInstallFilesGenerator(
@@ -46,7 +47,8 @@ static cmInstallFilesGenerator* CreateInstallFilesGenerator(
programs, args.GetPermissions().c_str(),
args.GetConfigurations(), args.GetComponent().c_str(),
message,
-args.GetRename().c_str(), args.GetOptional());
+args.GetExcludeFromAll(), args.GetRename().c_str(),
+args.GetOptional());
}
@@ -116,6 +118,7 @@ bool cmInstallCommand::HandleScriptMode(std::vectorstd::string const args)
int componentCount = 0;
bool doing_script = false;
bool doing_code = false;
+ bool exclude_from_all = false;
// Scan the args once for COMPONENT. Only allow one.
//
@@ -127,6 +130,10 @@ bool cmInstallCommand::HandleScriptMode(std::vectorstd::string const args)
++i;
component = args[i];
}
+if(args[i] == EXCLUDE_FROM_ALL)
+{
+exclude_from_all = true;
+}
}
if(componentCount1)
@@ -174,7 +181,7 @@ bool cmInstallCommand::HandleScriptMode(std::vectorstd::string const args)
}
this-Makefile-AddInstallGenerator(
new cmInstallScriptGenerator(script.c_str(), false,
- component.c_str()));
+ component.c_str(), exclude_from_all));
}
else if(doing_code)
{
@@ -182,7 +199,7 @@ bool cmInstallCommand::HandleScriptMode(std::vectorstd::string const args)
std::string code = args[i];
this-Makefile-AddInstallGenerator(
new cmInstallScriptGenerator(code.c_str(), true,
- component.c_str()));
+ component.c_str(), exclude_from_all));
}
}
@@ -906,6 +913,7 @@ cmInstallCommand::HandleDirectoryMode(std::vectorstd::string const args)
Doing doing = DoingDirs;
bool in_match_mode = false;
bool optional = false;
+ bool exclude_from_all = false;
bool message_never = false;
std::vectorstd::string dirs;
const char* destination = 0;
@@ -1087,6 +1095,19 @@ cmInstallCommand::HandleDirectoryMode(std::vectorstd::string const args)
// Switch to setting the component property.
doing = DoingComponent;
}
+else if(args[i] == EXCLUDE_FROM_ALL)
+ {
+ if(in_match_mode)
+{
+std::ostringstream e;
+e args[0] does not allow \
+ args[i] \ after PATTERN or REGEX.;
+this-SetError(e.str().c_str());
+return false;
+}
+ exclude_from_all = true;
+ doing = DoingNone;
+ }
else if(doing == DoingDirs)
{
// Convert this directory to a full path.
@@ -1230,6 +1251,7 @@ cmInstallCommand::HandleDirectoryMode(std::vectorstd::string const args)
configurations,
component.c_str(),
message,
+exclude_from_all,
literal_args.c_str(),
optional));
@@ -1357,7 +1379,8 @@ bool cmInstallCommand::HandleExportMode(std::vectorstd::string const args)
exportSet,
ica.GetDestination().c_str(),
ica.GetPermissions().c_str(), ica.GetConfigurations(),
- ica.GetComponent().c_str(), message, fname.c_str(),
+ ica.GetComponent().c_str(), message,
+ ica.GetExcludeFromAll(), fname.c_str(),
name_space.GetCString(), exportOld.IsEnabled(), this-Makefile);
this-Makefile-AddInstallGenerator(exportGenerator);
diff --git
Re: [cmake-developers] [CMake] CTest threshold exceeds 1024 bytes
On 07/21/2015 04:12 AM, Roman Wüger wrote: Is there a way to get the full output without modifying every CMake Script of about ~ 35 projects? CTest always truncates the output of passing tests unless the test output contains the literal text CTEST_FULL_OUTPUT. This was done long ago to limit the size of submissions of passed tests. CTest will have to be taught an option to skip this. Take a look at the definition and uses of CleanTestOutput in Source/CTest. There are already variables like CustomMaximumPassedTestOutputSize internally but it looks like there is no way to configure them at runtime. -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] Generator expressions for archive|library|runtime output directory
On 07/17/2015 02:34 PM, Robert Goulet wrote:
I'm going to be away for a few weeks, is it ok if the master branch
stays in that state for a while?
Okay. I've made a note about this issue to make sure it is fixed before 3.4.
Meanwhile I have another comment on genex support in the OUTPUT_DIRECTORY
properties. Currently the properties support both
{ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY
and
{ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY_CONFIG
variants. When the former is used CMake will still add the /CONFIG
directory suffix to the end of the value. When the latter is used
CMake does not do this.
With the former, when a genex like $CONFIG is used, it is likely
that the user does not want CMake to add the /CONFIG suffix.
Perhaps we should detect when a genex is present in the value and
skip adding the suffix, thus trusting the user to have done the right
thing (e.g. $1:value will still not get a suffix).
Of course this would have to be documented carefully. We could also
disallow a genex in the latter (per-config) variants to encourage
modern use of the former.
-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] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications
On 07/19/2015 03:07 PM, Ralf Habacker wrote: The check is performed with CheckFunctionExists.c, which converts the function name into a prototype of the form 'char BZ2_bzCompressInit()', while in real it is int BZ2_bzCompressInit ( bz_stream *strm, int blockSize100k, int verbosity, int workFactor ); Rather than (or in addition to) changing to _BZ2_decompress, please look at changing the check to use CheckSymbolExists. It allows the actual header to be included so we can test using the library the way the project will. That is likely more robust. Note that you may need to set CMAKE_REQUIRED_INCLUDES and CMAKE_REQUIRED_LIBRARIES to make sure the check is run with the desired bzip2 library. 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] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications
Am 21.07.2015 um 15:46 schrieb Brad King:
Rather than (or in addition to) changing to _BZ2_decompress, please look
at changing the check to use CheckSymbolExists. It allows the actual
header to be included so we can test using the library the way the
project will. That is likely more robust. Note that you may need
to set CMAKE_REQUIRED_INCLUDES and CMAKE_REQUIRED_LIBRARIES to make
sure the check is run with the desired bzip2 library.
Changed to use CheckSymbolExists, see append patch.
Regards
Ralf
--- a/Modules/FindBZip2.cmake 2015-07-21 15:53:01.529240144 +0200
+++ b/Modules/FindBZip2.cmake 2015-07-21 16:23:19.789187460 +0200
@@ -56,11 +56,12 @@
VERSION_VAR BZIP2_VERSION_STRING)
if (BZIP2_FOUND)
- include(${CMAKE_CURRENT_LIST_DIR}/CheckLibraryExists.cmake)
+ include(${CMAKE_CURRENT_LIST_DIR}/CheckSymbolExists.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/CMakePushCheckState.cmake)
cmake_push_check_state()
set(CMAKE_REQUIRED_QUIET ${BZip2_FIND_QUIETLY})
- CHECK_LIBRARY_EXISTS(${BZIP2_LIBRARIES} BZ2_bzCompressInit BZIP2_NEED_PREFIX)
+ set(CMAKE_REQUIRED_LIBRARIES ${BZIP2_LIBRARIES})
+ CHECK_SYMBOL_EXISTS(BZ2_bzCompressInit bzlib.h BZIP2_NEED_PREFIX)
cmake_pop_check_state()
endif ()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications
On 07/21/2015 10:32 AM, Ralf Habacker wrote: Changed to use CheckSymbolExists, see append patch. Thanks. We'll also need to set CMAKE_REQUIRED_INCLUDES to ensure the correct bzlib.h header can be found when it is not in a system default location. 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
