[cmake-developers] Issue: 12592 New componentwise extra install commands for NSIS-generator
Hello, did someone work on this? (http://public.kitware.com/Bug/view.php?id=12592) Is there an alternative to use extra install commands per component? 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] CTest threshold exceeds 1024 bytes
Hello Brad, I made the atoi change but my problem is the test itself. I don't know how to specify the command line parameter and check the generated xml file. Best Regards RomN Am 27.07.2015 um 17:52 schrieb Brad King brad.k...@kitware.com: On 07/23/2015 03:23 AM, Roman Wüger wrote: I don't know how to use the -check.cmake scripts to check the length of the output. My advice to use Tests/RunCMake/CTestCommandLine turns out to be incorrect. Use Tests/RunCMake/ctest_test instead because that one actually produces the .xml file. See the TestChangeId case for another example that checks the .xml file content. Also please change from atoi to StringToLong and issue a warning if the conversion of the specified value fails (see --test-load for an example). Then add a test covering this warning for each option. 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
[cmake-developers] [CMake 0015705]: Sets SONAME for modules
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15705 == Reported By:Felix Geyer Assigned To: == Project:CMake Issue ID: 15705 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-20 08:19 EDT Last Modified: 2015-08-20 08:19 EDT == Summary:Sets SONAME for modules Description: cmake sets an SONAME for modules by default which doesn't make much sense. It's only useful for shared libraries that application link against. In particular this is a problem for Debian as it has tools to track which symbols are exported by libraries. This tool looks at all shared libraries that have an SONAME so currently it also records the symbols of plugins generated by cmake-using projects. Attached is a patch that changes this behavior in cmake. == Issue History Date ModifiedUsername FieldChange == 2015-08-20 08:19 Felix GeyerNew Issue 2015-08-20 08:19 Felix GeyerFile Added: 0001-Don-t-set-SONAME-for-modules.patch == -- 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] Making kwsys a proper library
On 08/17/2015 09:52 AM, Brad King wrote: On 08/15/2015 12:20 AM, Orion Poplawski wrote: What makes the kwsys code special in a way that makes creating a shared library inappropriate? We want to share the code across projects but we don't want it to get in the way of those projects evolving or releasing. KWSys has no version number or API version level, and we don't want to maintain one. Exactly one version of KWSys is used by each version of our consuming projects, down to the granularity of individual commits on each side. We want to remain free to make incompatible changes at any time. Dependents update their source and port to such changes when they are ready, not when some user decides to try that particular combination of versions. We don't have to worry about mixing versions in different dependents (due to prefix configuration), or about forward or backward compatibility on either end of the dependency arrows (due to version locking at the source level). -Brad The consensus of the FPC is that the current situation with KWSys is very undesirable. While this approach may have been reasonable years ago with few consumers, it does not seem acceptable at this point. In particular it contains string processing and process handling code that could be security sensitive. See http://meetbot.fedoraproject.org/fedora-meeting-1/2015-08-20/fpc.2015-08-20-16.00.log.html for a full transcript of the meeting. Any and all efforts by the KWSys maintainers to split out KWSys into proper libraries and perhaps pull out code that is only use by a single project into that project would be greatly appreciated. It would also be greatly appreciated if KWSys using projects would include in their tarballs only those components that they actually used. Currently Fedora will start marking KWSys using projects with a: Provides: bundled(kwsys-COMPONENT) tag to try to keep track of what each project uses. We hope to revisit the situation in the future. Thank you for your consideration. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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] ExternalProject: Use native paths as substitute for directory tokens
Hi,
Funny you are mailing the list about this, since I just ran into this same
issue today building something totally different from Boost... In this case
it's a build tool that thinks the /U in C:/Users is a new command line
argument, that isn't recognized - and then the subsequent s also ends up
unrecognized... and it all fails... And it has nothing to do with the working
directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me.
I think the issue with globally making this change to the existing tokens is
that there could be some external tool/program that is EXPECTING to get CMake
paths, not native paths. Who knows? I am guessing that is what David Cole was
concerned about.
Maybe the right answer is to introduce some NEW tokens while leaving the
behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be
good if the patch updates the documentation of ExternalProject and clearly
states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user
can pick whichever one suits them best, depending on the tool being invoked.
Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a
CMake path, not native path. For example, if the token is being found in a
property like WORKING_DIRECTORY that eventually gets passed to
add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake
path. I am guessing this is what David Cole was also concerned about.
I still think your original method of building Boost is a bit unusual and would
be better served by _Add_Step with a custom working directory - because that's
the publicly documented/standard way of changing the working directory, but
that is up to you. :)
Best regards,
James Johnston
On Thu, 20 Aug 2015 14:37:08 + Stefan Kislinskiy
s.kislins...@dkfz-heidelberg.de wrote
Hi,
thank you for our suggestions. I am aware that I can solve my example
differently and that it might look not directly connected the proposal, but
well, it is an example just to show a single case and why it matters. :) I
did not want to discuss the example itself. Working around here would just
resolve a symptom.
My point is the overall problem that would persist: A big part of
ExternalProject is to issue commands for predefined and custom steps. Those
commands are supposed to be executed by the shell/command line. According to
the documentation and the source code of ExternalProject, directory tokens
are mainly supposed to be replaced in commands. It is my understanding, that
it is a bug, if CMake isn't able to assemble these commands correctly. This
would include usage of the correct path style of the OS for shell/command
line commands. As directory tokens are replaced internally right before a
shell/command line command is assembled, I can't see why this would be kind
of API-breaking. You cannot interfere in your CMake code with these
internal replacements.
Therefore I would still prefer my solution as it is pretty simple without
adding even more features to ExternalProject and in my opinion without
breaking code in the wild. It is a true bug fix instead of a feature request
for working directories, which is a different topic that just coincidentally
arised because of my specific example I guess. The features you described
wouldn't fix the actual bug.
As you were not sure if my approach would even fix my problems: It does of
course and this is what I am currently doing and what I tested extensively
before creating the patch. :) Regarding your quote from the
add_custom_command documentation I can tell you that this is how things are
currently done in ExternalProject and always were as far as I know, for
example (from ExternalProject.cmake):
add_custom_command(
OUTPUT ${stamp_file}
BYPRODUCTS ${byproducts}
COMMENT ${comment}
COMMAND ${command}
COMMAND ${touch}
DEPENDS ${depends}
WORKING_DIRECTORY ${work_dir}
VERBATIM
)
Best regards,
Stefan
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf
Of James Johnston
Sent: Donnerstag, 20. August 2015 15:37
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Kislinskiy, Stefan
Sent: Thursday, August 20, 2015 09:02
To: David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
Hi David,
Example excerpt (it is not possible to change the working directory
for
the
CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
Hi,
thank you for our suggestions. I am aware that I can solve my example
differently and that it might look not directly connected the proposal, but
well, it is an example just to show a single case and why it matters. :) I did
not want to discuss the example itself. Working around here would just resolve
a symptom.
My point is the overall problem that would persist: A big part of
ExternalProject is to issue commands for predefined and custom steps. Those
commands are supposed to be executed by the shell/command line. According to
the documentation and the source code of ExternalProject, directory tokens are
mainly supposed to be replaced in commands. It is my understanding, that it is
a bug, if CMake isn't able to assemble these commands correctly. This would
include usage of the correct path style of the OS for shell/command line
commands. As directory tokens are replaced internally right before a
shell/command line command is assembled, I can't see why this would be kind of
API-breaking. You cannot interfere in your CMake code with these internal
replacements.
Therefore I would still prefer my solution as it is pretty simple without
adding even more features to ExternalProject and in my opinion without breaking
code in the wild. It is a true bug fix instead of a feature request for working
directories, which is a different topic that just coincidentally arised because
of my specific example I guess. The features you described wouldn't fix the
actual bug.
As you were not sure if my approach would even fix my problems: It does of
course and this is what I am currently doing and what I tested extensively
before creating the patch. :) Regarding your quote from the add_custom_command
documentation I can tell you that this is how things are currently done in
ExternalProject and always were as far as I know, for example (from
ExternalProject.cmake):
add_custom_command(
OUTPUT ${stamp_file}
BYPRODUCTS ${byproducts}
COMMENT ${comment}
COMMAND ${command}
COMMAND ${touch}
DEPENDS ${depends}
WORKING_DIRECTORY ${work_dir}
VERBATIM
)
Best regards,
Stefan
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of
James Johnston
Sent: Donnerstag, 20. August 2015 15:37
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute
for directory tokens
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Kislinskiy, Stefan
Sent: Thursday, August 20, 2015 09:02
To: David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
Hi David,
Example excerpt (it is not possible to change the working directory
for
the
CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
sufficient):
This doesn't really directly have to do with your proposal, but what if an
option was added to change the working dir of the CONFIGURE_COMMAND? E.g.
WORKING_DIRECTORY_CONFIGURE. And suppose you'd have it recognize the various
tags like SOURCE_DIR, etc. This might be useful to add to other steps as
well, and would be more portable than your solution which is using
cmd.exe-specific commands. You'd want to audit for any resulting breakage
(e.g. does ExternalProject make assumptions that the working directory of
CONFIGURE is always the binary dir? - e.g. a relative path being used
somewhere. And probably only allow specification of
WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as the
built-in commands certainly assume the default working dir.)
In your situation though, I'm not sure it's strictly needed. From your sample,
it looks like you're building boost. In your case what if you:
* Use ExternalProject_Add_Step to bootstrap. You can specify a
WORKING_DIRECTORY here. Note one problem: you can't do out of source build of
b2, which breaks user expectations.
* Then use ExternalProject_Add_Step to build Boost.
Yes, using _Add_Step is somewhat of a workaround, but in this case, I've found
it wasn't much of a burden at all. In fact the only case I can think of where
it WOULD be a burden would be if the configure step is CMake. But then you
wouldn't need to change the working directory; changing it would break CMake.
In practice nobody will want to change WORKING_DIRECTORY unless it's a custom
command and then it's easy to use _Add_Step anyway.
That said, it might still be considered a little undesired and so maybe my
proposal above would be a better way to handle it.
Corrections from maintainers and others on the above commentary are welcome...
set(bootstrap_cmd SOURCE_DIR/bootstrap${shell_ext}
${bootstrap_toolset})
if(WIN32)
set(bootstrap_cmd pushd SOURCE_DIR COMMAND ${bootstrap_cmd}
COMMAND popd)
endif()
ExternalProject_Add(Boost
...
[cmake-developers] [CMake 0015697]: CUDA separable compilation intermediate file doesn't get created
The following issue is now in status NEW (again) == https://public.kitware.com/Bug/view.php?id=15697 == Reported By:Dominic Meiser Assigned To: == Project:CMake Issue ID: 15697 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-14 16:37 EDT Last Modified: 2015-08-20 10:42 EDT == Summary:CUDA separable compilation intermediate file doesn't get created Description: When I compile with CUDA_SEPARABLE_COMPILATION=TRUE the custom command for the generation of the intermediate_link.obj does not get triggered. When I change line 1590 in FindCUDA.cmake (master version from earlier today) to `set(do_obj_build_rule TRUE)` the custom command does run and compilation succeeds. I don't see the bug here. I'm seeing this behavior with cmake 3.2.2 and master revision 17ecfd8210. Steps to Reproduce: configure a cuda library target with CUDA_SEPARABLE_COMPILATION=TRUE and build. Additional Information: This is with cuda toolkit 7.0 == -- (0039283) Dominic Meiser (reporter) - 2015-08-14 17:49 https://public.kitware.com/Bug/view.php?id=15697#c39283 -- I must have made a mistake earlier. I cannot reproduce this with master anymore. Sorry for the bother. -- (0039306) Dominic Meiser (reporter) - 2015-08-20 10:20 https://public.kitware.com/Bug/view.php?id=15697#c39306 -- Turns out I wasn't able to reproduce the issue because I switched compilers to VS2012 and VS2010. But when I went back to VS 2013 the problem is reproducible. It appears that the workaround for the object build rules used for VS2010 and VS2012 does not work for VS2013. Apparently the multilevel object dependency problem has been fixed in VS2013. The attached patch solves the problem for me. -- (0039307) Dominic Meiser (reporter) - 2015-08-20 10:28 https://public.kitware.com/Bug/view.php?id=15697#c39307 -- See note https://public.kitware.com/Bug/view.php?id=39306 for explanation of why I wasn't able to reproduce this earlier. Issue History Date ModifiedUsername FieldChange == 2015-08-14 16:37 Dominic Meiser New Issue 2015-08-14 17:49 Dominic Meiser Note Added: 0039283 2015-08-17 09:38 Brad King Status new = resolved 2015-08-17 09:38 Brad King Resolution open = unable to reproduce 2015-08-17 09:38 Brad King Issue Monitored: Brad King 2015-08-20 10:20 Dominic Meiser Note Added: 0039306 2015-08-20 10:21 Dominic Meiser File Added: 0001-FindCUDA.cmake-Fix-object-build-rule-for-separate-co.patch 2015-08-20 10:23 Dominic Meiser Issue Monitored: Dominic Meiser 2015-08-20 10:28 Dominic Meiser Note Added: 0039307 2015-08-20 10:28 Dominic Meiser Status resolved = feedback 2015-08-20 10:28 Dominic Meiser Resolution unable to reproduce = reopened 2015-08-20 10:42 Brad King Status feedback = new 2015-08-20 10:42 Brad King Resolution reopened = open == -- 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] ExternalProject: Use native paths as substitute for directory tokens
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Kislinskiy, Stefan
Sent: Thursday, August 20, 2015 09:02
To: David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
Hi David,
Example excerpt (it is not possible to change the working directory for
the
CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
sufficient):
This doesn't really directly have to do with your proposal, but what if an
option was added to change the working dir of the CONFIGURE_COMMAND? E.g.
WORKING_DIRECTORY_CONFIGURE. And suppose you'd have it recognize the
various tags like SOURCE_DIR, etc. This might be useful to add to other
steps as well, and would be more portable than your solution which is using
cmd.exe-specific commands. You'd want to audit for any resulting breakage
(e.g. does ExternalProject make assumptions that the working directory of
CONFIGURE is always the binary dir? - e.g. a relative path being used
somewhere. And probably only allow specification of
WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as
the built-in commands certainly assume the default working dir.)
In your situation though, I'm not sure it's strictly needed. From your
sample, it looks like you're building boost. In your case what if you:
* Use ExternalProject_Add_Step to bootstrap. You can specify a
WORKING_DIRECTORY here. Note one problem: you can't do out of source build
of b2, which breaks user expectations.
* Then use ExternalProject_Add_Step to build Boost.
Yes, using _Add_Step is somewhat of a workaround, but in this case, I've
found it wasn't much of a burden at all. In fact the only case I can think
of where it WOULD be a burden would be if the configure step is CMake. But
then you wouldn't need to change the working directory; changing it would
break CMake. In practice nobody will want to change WORKING_DIRECTORY
unless it's a custom command and then it's easy to use _Add_Step anyway.
That said, it might still be considered a little undesired and so maybe my
proposal above would be a better way to handle it.
Corrections from maintainers and others on the above commentary are
welcome...
set(bootstrap_cmd SOURCE_DIR/bootstrap${shell_ext}
${bootstrap_toolset})
if(WIN32)
set(bootstrap_cmd pushd SOURCE_DIR COMMAND ${bootstrap_cmd}
COMMAND popd)
endif()
ExternalProject_Add(Boost
...
CONFIGURE_COMMAND ${bootstrap_cmd}
...
)
From add_custom_command: If more than one COMMAND is specified they will
be executed in order, but not necessarily composed into a stateful shell or
batch script.
So I am not sure your approach will work for you even if you fix the issue
with path slashes.
James
--
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] ExternalProject: Use native paths as substitute for directory tokens
It's exactly what I am concerned about:
You're asking to change the behavior of something for EVERYONE to
solve a problem which you have encountered. If you change it the way
you have proposed, you will cause problems for others. It has worked
the way it is now since ExternalProject_Add was introduced in CMake
2.8. Changing it unconditionally the way you propose is simply not
feasible for backwards compatibility.
I think commands that take native paths ought NOT to use the *_DIR
replacement values, and instead, ought to pass in variables that
contain the native paths in the first place.
David C.
On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
johnstonj.pub...@codenest.com wrote:
Hi,
Funny you are mailing the list about this, since I just ran into this same
issue today building something totally different from Boost... In this case
it's a build tool that thinks the /U in C:/Users is a new command line
argument, that isn't recognized - and then the subsequent s also ends up
unrecognized... and it all fails... And it has nothing to do with the
working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible
workaround for me.
I think the issue with globally making this change to the existing tokens is
that there could be some external tool/program that is EXPECTING to get CMake
paths, not native paths. Who knows? I am guessing that is what David Cole
was concerned about.
Maybe the right answer is to introduce some NEW tokens while leaving the
behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would
be good if the patch updates the documentation of ExternalProject and clearly
states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user
can pick whichever one suits them best, depending on the tool being invoked.
Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a
CMake path, not native path. For example, if the token is being found in a
property like WORKING_DIRECTORY that eventually gets passed to
add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a
CMake path. I am guessing this is what David Cole was also concerned about.
I still think your original method of building Boost is a bit unusual and
would be better served by _Add_Step with a custom working directory - because
that's the publicly documented/standard way of changing the working
directory, but that is up to you. :)
Best regards,
James Johnston
On Thu, 20 Aug 2015 14:37:08 + Stefan Kislinskiy
s.kislins...@dkfz-heidelberg.de wrote
Hi,
thank you for our suggestions. I am aware that I can solve my example
differently and that it might look not directly connected the proposal, but
well, it is an example just to show a single case and why it matters. :) I
did not want to discuss the example itself. Working around here would just
resolve a symptom.
My point is the overall problem that would persist: A big part of
ExternalProject is to issue commands for predefined and custom steps. Those
commands are supposed to be executed by the shell/command line. According to
the documentation and the source code of ExternalProject, directory tokens
are mainly supposed to be replaced in commands. It is my understanding, that
it is a bug, if CMake isn't able to assemble these commands correctly. This
would include usage of the correct path style of the OS for shell/command
line commands. As directory tokens are replaced internally right before a
shell/command line command is assembled, I can't see why this would be kind
of API-breaking. You cannot interfere in your CMake code with these
internal replacements.
Therefore I would still prefer my solution as it is pretty simple without
adding even more features to ExternalProject and in my opinion without
breaking code in the wild. It is a true bug fix instead of a feature request
for working directories, which is a different topic that just coincidentally
arised because of my specific example I guess. The features you described
wouldn't fix the actual bug.
As you were not sure if my approach would even fix my problems: It does of
course and this is what I am currently doing and what I tested extensively
before creating the patch. :) Regarding your quote from the
add_custom_command documentation I can tell you that this is how things are
currently done in ExternalProject and always were as far as I know, for
example (from ExternalProject.cmake):
add_custom_command(
OUTPUT ${stamp_file}
BYPRODUCTS ${byproducts}
COMMENT ${comment}
COMMAND ${command}
COMMAND ${touch}
DEPENDS ${depends}
WORKING_DIRECTORY ${work_dir}
VERBATIM
)
Best regards,
Stefan
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On
Behalf Of James Johnston
Sent: Donnerstag, 20.
Re: [cmake-developers] CTest threshold exceeds 1024 bytes
On 08/20/2015 06:30 AM, Roman Wüger wrote: I made the atoi change but my problem is the test itself. I don't know how to specify the command line parameter and check the generated xml file. Okay, please post the latest version of the patch so far and I'll see if I can find a chance to work on the test. 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] Recursion in OUTPUT_NAME genex
On 08/18/2015 03:25 PM, Robert Goulet wrote: Please try new patch in attachment, this might fix it. Thanks. Based on that I constructed a slightly simpler version by using pair as the key: cmGeneratorTarget: Avoid recursion in GetOutputName method http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c37d264 -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] ExternalProject: Use native paths as substitute for directory tokens
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of David Cole via cmake-developers Sent: Thursday, August 20, 2015 21:21 To: James Johnston Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. Right, agreed that the original *_DIR behavior would need to remain unchanged. But how would you know what the binary directory of the external project is, before calling ExternalProject_Add? It's too early to call ExternalProject_Get_Property(target BINARY_DIR). I assume that is why BINARY_DIR and friends exist, as the location will be affected via various ExternalProject parameters. From the doc: The *_DIR options specify directories for the project, with default directories computed as follows snip Quite a set of rules follow and if one is trying to use the binary directory in the path to some build tool, it's handy to put BINARY_DIR in the command. But if you need a native path for your build tool, BINARY_DIR doesn't work as Stefan Kislinskiy noted, which is why I suggested making new tokens might be a viable alternative, e.g. BINARY_DIR_NATIVE? Best regards, James Johnston -- 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
