Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote:
On 01/30/2013 12:09 PM, Stephen Kelly wrote:
We can document that $TARGET_DEFINED has scope only in the current
project and will be processed away during export. I do not think we
want an upstream interface modifying its behavior based on the mere
presence of an arbitrary target in the downstream anyway.
Thoughts on this behavior?
I've left it in on export because it might make sense to use it with
generator expressions even on export:
set(lib_genex $$CONFIG:Debug:debuglib)
tll(tgt $TARGET_DEFINED:${lib_genex}:$TARGET_PROPERTY:${lib_genex},FOO)
Another thought is to have tll() only append includes/defines if the
target is already defined at the call site and otherwise do nothing.
When I previously pointed out the need for handling not-yet-defined
targets I did not realize the cost.
I've made the LINKED generator expression a first-class expression, not just
something to be preprocessed away. I think this addresses much of the cost
concern.
In the KDE frameworks case, it was very useful to be able to refer to
targets which were not defined yet, which was why I implemented it.
It was useful for two reasons. One was that often the use of
add_subdirectory(tests) appeared before the target it was testing (which tll
handles), and another was the use of targets as dependencies of other
library targets before that target was defined (and where re-ordering of the
top-level directories doesn't seem to be possible).
So, I would prefer to keep that feature.
We could even go as far as not adding the generator expression to
INCLUDE_DIRECTORIES if the target dependency does not have an
INTERFACE_INCLUDE_DIRECTORIES already defined too (and similarly for
COMPILE_DEFINITIONS).
Advantages:
* Very little overhead for non-target arguments
* Very little overhead for targets without interfaces
* Works in the motivating case of using targets imported from an upstream
Disadvantages:
* Does not work automatically for circular dependencies.
* Does not work if the target is not defined yet, even in the non-circular
case
* Assumes that interface includes are set before the tll() call. (ie it
does not work so well in the motivating case of non-imported targets)
It would break this:
add_library(foo ...)
add_library(bar ...)
target_link_libraries(foo bar)
target_include_directories(bar INTERFACE /usr/include/bar)
* Transitive linking is handled in C++ code rather than in generator
expressions so there is no bloat in the LINK_LIBRARIES properties
for non-target elements like the above. Perhaps we can have a special
generator expression that has context-sensitive evaluation e.g.
$LINKED:blah
That makes sense to me. I don't have time to do it right now though.
Maybe I can do it later.
Perhaps there is no need for it if we use the simpler approach above.
I've implemented the approach with LINKED in the tll-includes-defines branch
in my clone. I think it's reasonably simple, compact and acceptable.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/31/2013 05:34 AM, Stephen Kelly wrote:
I've left it in on export because it might make sense to use it with
generator expressions even on export:
set(lib_genex $$CONFIG:Debug:debuglib)
tll(tgt $TARGET_DEFINED:${lib_genex}:$TARGET_PROPERTY:${lib_genex},FOO)
Okay. As long as $LINKED:... is removed for non-targets then this won't
be an issue. I see your branch does this already :)
I've made the LINKED generator expression a first-class expression, not just
something to be preprocessed away. I think this addresses much of the cost
concern.
Nice! Here are a few comments:
* I got a warning while building your branch:
.../Source/cmExportFileGenerator.cxx: In member function ‘void
cmExportFileGenerator::ResolveTargetsInGeneratorExpression(std::string,
cmTarget*, std::vectorstd::basic_stringchar )’:
.../Source/cmExportFileGenerator.cxx:425:12: warning: unused variable ‘error’
[-Wunused-variable]
* I think $LINKED:... can be removed completely on export. If the
item is not a target then remove it (already done in your impl).
If it is a target then replace it with the appropriate
$TARGET_PROPERTY:...,... reference in the export. This way the
$LINKED:... expression lives only as long as needed.
* We could document $LINKED:... it as an internal implementation
detail subject to future changes. It should never be written by
a project, only by tll. It is transformed properly on export.
I'd like to leave room for an alternative solution to out-of-order
target interfaces in the future.
* Can the INCLUDE_DIRETORIES and COMPILE_DEFINITIONS property avoid
$LINKED:foo references if foo is linked more than once? Skip
appending it if the same reference already exists earlier. In
the BEFORE case, prepend it and remove later instances.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote: I've made the LINKED generator expression a first-class expression, not just something to be preprocessed away. I think this addresses much of the cost concern. Nice! Here are a few comments: * I got a warning while building your branch: .../Source/cmExportFileGenerator.cxx: In member function ‘void cmExportFileGenerator::ResolveTargetsInGeneratorExpression(std::string, cmTarget*, std::vectorstd::basic_stringchar )’: .../Source/cmExportFileGenerator.cxx:425:12: warning: unused variable ‘error’ [-Wunused-variable] Fixed now, thanks. * I think $LINKED:... can be removed completely on export. Yes, it can be. What you describe below was my initial implementation, and I can change it back to that. I left it as $LINKED so far so that it is a shorter string, and because the implementation is somewhat simpler. I've pushed another patch doing the replacement. If the item is not a target then remove it (already done in your impl). If it is a target then replace it with the appropriate $TARGET_PROPERTY:...,... reference in the export. This way the $LINKED:... expression lives only as long as needed. * We could document $LINKED:... it as an internal implementation detail subject to future changes. It should never be written by a project, only by tll. Ok. It is transformed properly on export. I'd like to leave room for an alternative solution to out-of-order target interfaces in the future. * Can the INCLUDE_DIRETORIES and COMPILE_DEFINITIONS property avoid $LINKED:foo references if foo is linked more than once? Skip appending it if the same reference already exists earlier. In the BEFORE case, prepend it and remove later instances. Yes I'm sure that can be done. Do you think it needs to be done before merging to next? Anything else to do before merging it? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/31/2013 10:23 AM, Stephen Kelly wrote:
I left it as $LINKED so far so that it is a shorter string, and because
the implementation is somewhat simpler.
Ahh, I see you were using $LINKED:... even for already-defined targets.
I think that is fine during processing of the same project to keep the
strings shorter. We still need to keep it out of the exported interface
so that we can change it later without having to keep the expression
implementation around to support old export files. This way it never
outlives the CMake process that generated it.
Do you think it needs to be done before merging to next?
De-duplication of $LINKED references can be added later but I'd still
like to see it before the 2.8.11 release so that it doesn't become a
behavior change later.
Anything else to do before merging it?
Please add a test case for the $INSTALL_PREFIX evaluation error.
What is the purpose of the else case here?
+ std::string value = !isGenex ? $LINKED: + lib +
+ : $$TARGET_DEFINED: + lib + : +
+ $TARGET_PROPERTY: + lib +
+ ,INTERFACE_ + property +
+ ;
If the input is already a genex isn't the author responsible for
making sure it is valid?
The documentation of package_NO_INTERFACES and package_INTERFACES
reference ${CMAKE_FIND_PACKAGE_NAME}_FIND_VERSION but the corresponding
package_FIND_VERSION isn't documented until further down. Please move
the new docs to the bottom, but still above the NO_POLICY_SCOPE line.
Also the current wording of the documentation makes it sound like 2.8.11
is at fault for introducing incompatibility. There is no need to mention
the version of CMake there. It is the version of the upstream that
starts using the new features that causes a problem.
It should be clear that the upstream is responsible for adding the example
code to set the package_NO_INTERFACES variable in their package config
file when it exposes the new interfaces. Also package_INTERFACES is to
be set by the downstream and used by that code in the upstream.
Then merge for testing!
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] So Long
David, I wish you the best for your new adventure. That was really nice interacting with you for improving CMake. Regards, Nico On Wed, Jan 30, 2013 at 8:37 PM, David Cole david.c...@kitware.com wrote: Howdy folks, Thought I'd ping the CMake mailing lists one last time before I have to give up david.c...@kitware.com... ;-) For those of you that haven't heard yet, I've just embarked on a new adventure with a little startup company called Neocis Inc. I'll still be a big huge fan (and user) of CMake, and will take the way of the source with me wherever I go from now on. Heck, I bet you'll even see some commits coming from my direction now and again. CMake is too awesome not to use: it tries to take on the monumental, nearly impossible task of abstracting software build systems for dozens of platforms, and keep up to date with the new ones that come out, and does a quite admirable job. I trust this community will continue to provide stable, reliable, regular releases of CMake well into the future. In fact, I'm counting on it. So long and thanks for all the... ...patches! David Cole (still sorta reachable via dlrd...@aol.com) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
--help-property and --help-property-list exist. I don't know why this is on the web and not there. Sent from my iPhone On Jan 31, 2013, at 2:27, ycollette.nos...@free.fr wrote: What about a new -help command: --help-properties ? Do I fill a bug report for that ? YC - Mail original - De: David Cole dlrd...@aol.com À: ycollette nospam ycollette.nos...@free.fr Cc: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:53:32 Objet: Re: [CMake] ctest and properties T he best test properties reference is available online at: http://cmake.org/cmake/help/v2.8.10/cmake.html#section_PropertiesonTests You can't get that same information from the ctest command line as of 2.8.10. The cte st command line help could use some love... -Original Message- From: ycollette.nospam ycollette.nos...@free.fr Cc: cmake cmake@cmake.org Sent: Wed, Jan 30, 2013 10:47 am Subject: Re: [CMake] ctest and properties Thanks for the answer. In fact, the information I am looking for is located in cmake-2.8.10/2/Source/cmTest.cxx in the method void cmTest::DefineProperties(cmake *cm) line 98. I really don't know how to get this help from command line. I know that this information is context dependent (whether you use it from cmake or from test, on some kind of object like TEST in my case). YC - Mail original - De: Bill Hoffman bill.hoff...@kitware.com À: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:42:48 Objet: Re: [CMake] ctest and properties On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
Thanks. It works fine with cmake, but not with ctest. Here is the output I've got with version 2.8.7: ctest --help-property-list ctest version 2.8.7 Internal error: Properties of Global Scope list is empty. Internal error: Properties on Directories list is empty. Internal error: Properties on Targets list is empty. Internal error: Properties on Tests list is empty. Internal error: Properties on Source Files list is empty. Internal error: Properties on Cache Entries list is empty. And it would be nice to have the result of cmake --help-property-list sorted by section. Here, I've got a huge list of property and I am not able to see which one is used in tests and which one is used on files. YC - Mail original - De: Leif Walsh leif.wa...@gmail.com À: ycollette nospam ycollette.nos...@free.fr Cc: cmake@cmake.org Envoyé: Jeudi 31 Janvier 2013 13:03:14 Objet: Re: [CMake] ctest and properties --help-property and --help-property-list exist. I don't know why this is on the web and not there. Sent from my iPhone On Jan 31, 2013, at 2:27, ycollette.nos...@free.fr wrote: What about a new -help command: --help-properties ? Do I fill a bug report for that ? YC - Mail original - De: David Cole dlrd...@aol.com À: ycollette nospam ycollette.nos...@free.fr Cc: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:53:32 Objet: Re: [CMake] ctest and properties T he best test properties reference is available online at: http://cmake.org/cmake/help/v2.8.10/cmake.html#section_PropertiesonTests You can't get that same information from the ctest command line as of 2.8.10. The cte st command line help could use some love... -Original Message- From: ycollette.nospam ycollette.nos...@free.fr Cc: cmake cmake@cmake.org Sent: Wed, Jan 30, 2013 10:47 am Subject: Re: [CMake] ctest and properties Thanks for the answer. In fact, the information I am looking for is located in cmake-2.8.10/2/Source/cmTest.cxx in the method void cmTest::DefineProperties(cmake *cm) line 98. I really don't know how to get this help from command line. I know that this information is context dependent (whether you use it from cmake or from test, on some kind of object like TEST in my case). YC - Mail original - De: Bill Hoffman bill.hoff...@kitware.com À: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:42:48 Objet: Re: [CMake] ctest and properties On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] adding automatic handling of dependencies for swig-generated modules
Ok, I got no answer, so I'll try to be more specific, and cross post
to -dev, please answer where suitable:
1) is there a known recipe to deal dependency detection?
2) I found the IMPLICIT_DEPENDS option of add_custom_command which
suggests such support is possible, but implemented directly in cmake
source code. Am I right?
3) is there a way to update a target list of dependencies from a custom command?
I can imagine some tricks such as including from the CMakeLists.txt a
file which is the output of an add_custom_command. It is probably not
possible, is it?
4) can we add a rule to automatically run cmake when certain files are
changed? Better, only when the content changes, not when the mtime
changes.
Thank you for your guidance
Regards,
-- Sebastian
On Mon, Jan 28, 2013 at 3:39 PM, Sébastien Barthélémy
barthel...@crans.org wrote:
Hello all,
swig supports the -MM option which lists a module dependencies (C/C++
headers and other .i interface files). I'd like to use it in order
to let cmake know about these dependencies without user intervention.
In addition to reducing the user burden, that would also help managing
dependencies on files which are outside of the current cmake project.
For instance when a swig module extends another one.
Currently, the user has to list these dependencies in a
SWIG_MODULE_${modulename}_EXTRA_DEPS variable. If a user changes the
.i file to add a #include line, he should also edit the CMakeLists.txt
file to add the corresponding header to the list. Editing the
CMakeLists.txt will cause make to run cmake again, hence the new
dependency will be taken into account.
Apparently, there was an attempt already:
http://public.kitware.com/Bug/view.php?id=4147
Its inner workings are simple:
* first, in swig_add_module, call swig -MM on the interface file, in
order to gather the dependencies,
* then use add_custom_command to generate the wrapper code (call swig
without -MM) whenever a dependency changes.
I see two shortcomings with this implementation (please correct me if I'm
wrong)
* swig -MM fails if it cannot find an header, hence it should be
called *after* the headers generation. Because of this problem, the
patch was reverted. I fear the only solution here is to let the user
list these generated dependencies explicitly, and make the swig -MM
call depend on them. We could use the
SWIG_MODULE_${modulename}_EXTRA_DEPS variable for this.
* swig -MM is only called when cmake is run. If the user changes the
interface file to add a %include, make will call swig to generate the
wrappers, but won't call swig -MM again. So the new dependency will go
unnoticed.
This last problem is probably trickier. Maybe we could use a single
add_custom_command, which would
* call swig -MM
* compare the dependencies it gets against its current ones. If the
two sets differ, call cmake,
* call swig to generate the wrappers
But I'm not sure about how to save the current dependencies and
about the conditional call to cmake.
Maybe swig --MM could output to a file, whose (content) change would
trigger cmake?
I'm pretty sure this is a quite common scenario, is there a canonical
solution? Or another module doing the same kind of dependency analysis
where I should look for inspiration?
Regards,
-- Sébastien
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTEST_CUSTOM_TESTS_IGNORE regex?
On 2013-01-31 01:19, Leif Walsh wrote:
In CTestCustom.cmake, I use CTEST_CUSTOM_MEMCHECK_IGNORE and
CTEST_CUSTOM_TESTS_IGNORE to turn some long-running tests on and off (on
for nightlies, off for development test cycles).
I recently broke apart a rather large shell script that was used to run a
test under many scenarios into something like
foreach (a 0 1)
foreach (b 0 1)
foreach (c 0 1)
add_test(NAME big_test_${a}${b}${c} COMMAND big_test ${a} ${b} ${c})
endforeach (c)
endforeach (b)
endforeach (a)
...you get the idea. It generates somewhere in the realm of 2000 test
cases. Now they run in parallel, which is great, but I can no longer turn
off this suite of tests easily.
It would be great to do something like
list(APPEND CTEST_CUSTOM_TESTS_IGNORE 'big_test_.*')
Is this or something like it supported?
Well, since we're talking about regular expressions, the list
separator is '|'. Have you tried:
set(CTEST_CUSTOM_TESTS_IGNORE
${CTEST_CUSTOM_TESTS_IGNORE}|big_test_.*)
...?
(Supporting an *actual* list of regular expressions seems like a nice
enhancement request, but hopefully the above can work around it for now.)
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTEST_CUSTOM_TESTS_IGNORE regex?
This variable seems to be interpreted as a normal cmake ;-delimited list. I
currently use it that way for other tests. I haven't tried building it as a
regex but I kind of doubt that would work, since I know it works as a list.
If I have to I can duplicate the loops in CTestCustom.cmake but that has other
issues (code duplication, size of output when running with -V, maybe speed).
Sent from my iPhone
On Jan 31, 2013, at 14:02, Matthew Woehlke matthew.woeh...@kitware.com wrote:
On 2013-01-31 01:19, Leif Walsh wrote:
In CTestCustom.cmake, I use CTEST_CUSTOM_MEMCHECK_IGNORE and
CTEST_CUSTOM_TESTS_IGNORE to turn some long-running tests on and off (on
for nightlies, off for development test cycles).
I recently broke apart a rather large shell script that was used to run a
test under many scenarios into something like
foreach (a 0 1)
foreach (b 0 1)
foreach (c 0 1)
add_test(NAME big_test_${a}${b}${c} COMMAND big_test ${a} ${b} ${c})
endforeach (c)
endforeach (b)
endforeach (a)
...you get the idea. It generates somewhere in the realm of 2000 test
cases. Now they run in parallel, which is great, but I can no longer turn
off this suite of tests easily.
It would be great to do something like
list(APPEND CTEST_CUSTOM_TESTS_IGNORE 'big_test_.*')
Is this or something like it supported?
Well, since we're talking about regular expressions, the list separator is
'|'. Have you tried:
set(CTEST_CUSTOM_TESTS_IGNORE
${CTEST_CUSTOM_TESTS_IGNORE}|big_test_.*)
...?
(Supporting an *actual* list of regular expressions seems like a nice
enhancement request, but hopefully the above can work around it for now.)
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTEST_CUSTOM_TESTS_IGNORE regex?
On 2013-01-31 14:16, Leif Walsh wrote:
This variable seems to be interpreted as a normal cmake ;-delimited list.
Ah, I see. I misread your message as it is already a regex and didn't
take lists. (Which is a little odd that it *isn't* a regex, as the CTest
command line takes a regex...)
If you have a custom dashboard script, you might be able to change the
test section to run ctest with '-E'... but I've never attempted to do
such a thing.
Or you could try running '${CTEST_COMMAND} -N' and parsing the output to
build the list of tests to ignore...
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] unable to view file properties using CMAKE 2.8.7 in VS2010
Hey there. I created a bare minimum cmake project ADD_LIBRARY (foo foo.c) When I open that solution in VS2010 and right click on foo.c and select properties, the properties dialog comes up but when I try to view each property (C/C++ General, Optimization, Preprocessor, etc...), nothing displays. The view is literally blank. No fields, just white. If I make the same project using the visual studio 2010 wizard instead of cmake, I am able to see properties. Is there something I need to enable in CMAKE to see these properties or is this a bug? Thanks in advance! BA -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] unable to view file properties using CMAKE 2.8.7 in VS2010
Ah, this seems to be an issue with the generated files clashing with a bug in VS2010 https://connect.microsoft.com/VisualStudio/feedback/details/635294/using-absolute-path-in-clcompile-item-prevents-property-pages-from-showing Is there a workaround for this in 2.8.7? I'm stuck using that version due to issues I'm experiencing with newer CMAKE versions Thanks! BA From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Bryn Aspestrand Sent: Thursday, January 31, 2013 11:55 AM To: cmake@cmake.org Subject: [CMake] unable to view file properties using CMAKE 2.8.7 in VS2010 Hey there. I created a bare minimum cmake project ADD_LIBRARY (foo foo.c) When I open that solution in VS2010 and right click on foo.c and select properties, the properties dialog comes up but when I try to view each property (C/C++ General, Optimization, Preprocessor, etc...), nothing displays. The view is literally blank. No fields, just white. If I make the same project using the visual studio 2010 wizard instead of cmake, I am able to see properties. Is there something I need to enable in CMAKE to see these properties or is this a bug? Thanks in advance! BA -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTEST_CUSTOM_TESTS_IGNORE regex?
Ah I see. Yep, it would both make sense and work perfectly if it was a regex.
Sadly it would also break stuff. Maybe CTEST_CUSTOM_TESTS_IGNORE_REGEX would be
a sane feature request.
Sent from my iPhone
On Jan 31, 2013, at 14:51, Matthew Woehlke matthew.woeh...@kitware.com wrote:
On 2013-01-31 14:16, Leif Walsh wrote:
This variable seems to be interpreted as a normal cmake ;-delimited list.
Ah, I see. I misread your message as it is already a regex and didn't take
lists. (Which is a little odd that it *isn't* a regex, as the CTest command
line takes a regex...)
If you have a custom dashboard script, you might be able to change the test
section to run ctest with '-E'... but I've never attempted to do such a thing.
Or you could try running '${CTEST_COMMAND} -N' and parsing the output to
build the list of tests to ignore...
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] unable to view file properties using CMAKE 2.8.7 in VS2010
Hey there. I created a bare minimum cmake project ADD_LIBRARY (foo foo.c) When I open that solution in VS2010 and right click on foo.c and select properties, the properties dialog comes up but when I try to view each property (C/C++ General, Optimization, Preprocessor, etc…), nothing displays. The view is literally blank. No fields, just white. If I make the same project using the visual studio 2010 wizard instead of cmake, I am able to see properties. Is there something I need to enable in CMAKE to see these properties or is this a bug? Properties work for my projects in VisualStudio 2010 for me when using CMake-2.8.10.2 to generate my projects. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] unable to view file properties using CMAKE 2.8.7 in VS2010
Yeah, CMAKE changed to relative pathing in VS2010 projects which fixes the issue with a bug in VS but I unfortunately can't use the newest CMAKE. I'm stuck with 2.8.7 for now -Original Message- From: John Drescher [mailto:dresche...@gmail.com] Sent: Thursday, January 31, 2013 12:02 PM To: Bryn Aspestrand Cc: cmake@cmake.org Subject: Re: [CMake] unable to view file properties using CMAKE 2.8.7 in VS2010 Hey there. I created a bare minimum cmake project ADD_LIBRARY (foo foo.c) When I open that solution in VS2010 and right click on foo.c and select properties, the properties dialog comes up but when I try to view each property (C/C++ General, Optimization, Preprocessor, etc...), nothing displays. The view is literally blank. No fields, just white. If I make the same project using the visual studio 2010 wizard instead of cmake, I am able to see properties. Is there something I need to enable in CMAKE to see these properties or is this a bug? Properties work for my projects in VisualStudio 2010 for me when using CMake-2.8.10.2 to generate my projects. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] ITK + system installed gdcm question
I've successfully built itk 4.3.1 with system installed gdcm 2.3.0; however, when I tried to link itk using target_link_libraries in my own program, cmake automatically added some gdcm libs to the link list without correctly specify their absolute paths. I wonder how I can remove these automatically included gdcm libs since I can manually specify them in the cmake file. Or any other solutions? Thanks. Environment: cmake 2.8.7 itk 4.3.1 gdcm 2.3.0 winxp 32bit vc2008 ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1839-g3deada4
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 3deada4973a175503b6aef1abf8b4c271a7e1660 (commit)
via e7b579bd01690f27c82ee9cbda4b7023f4a3d6c9 (commit)
via 77cecb778ff1882d87401c1055ec06585462f787 (commit)
via 0b92602b816e2584db3781b120a1e5200da72ada (commit)
via 0fa7f69c0e2cdcd8b7ece400651ee7821b2ede4b (commit)
via 2c3654c3de718fe822f8960063373774fc019494 (commit)
via d4297d5697cd10114f8accb7a233aa1f5ebc50ab (commit)
via df4d2b28b24a3172daf1290070199633f7c46cf0 (commit)
via 7ceeba992b4fb35ca05760b3170e68f41dfc1bb5 (commit)
via 30268b46f8237f25c82858693c000f5da8ede6ad (commit)
from dadb32e4da4f7cd39e0b0e7eba1f46659ac3f6a0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3deada4973a175503b6aef1abf8b4c271a7e1660
commit 3deada4973a175503b6aef1abf8b4c271a7e1660
Merge: dadb32e e7b579b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 31 11:35:07 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 31 11:35:07 2013 -0500
Merge topic 'tll-includes-defines' into next
e7b579b Test workaround of bad interface include directories from depends.
77cecb7 Add includes and compile definitions with target_link_libraries.
0b92602 Add the $LINKED:... generator expression.
0fa7f69 Add API to check if we're reading a includes or defines property.
2c3654c Add a way to exclude INTERFACE properties from exported targets.
d4297d5 Export targets to a targets file, not a Config file.
df4d2b2 Make it an error for INSTALL_PREFIX to be evaluated.
7ceeba9 Advance more when preprocessing exported strings.
30268b4 Handle reading empty properties defined by the link interface.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7b579bd01690f27c82ee9cbda4b7023f4a3d6c9
commit e7b579bd01690f27c82ee9cbda4b7023f4a3d6c9
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Dec 21 18:28:58 2012 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Jan 31 17:34:20 2013 +0100
Test workaround of bad interface include directories from depends.
diff --git a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
index 21159e0..5387377 100644
--- a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
+++ b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
@@ -82,3 +82,44 @@ add_custom_target(test_custom_target
$TARGET_PROPERTY:TargetIncludeDirectories,COMPILE_DEFINITIONS
WORKING_DIRECTORY
${CMAKE_CURRENT_SOURCE_DIR})
+
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bad)
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/bad/common.h #error Should not be
included\n)
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/good)
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/good/common.h #include
\othergood.h\\n)
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/othergood)
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/othergood/othergood.h // No error\n)
+
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/libothergood.cpp // No content \n)
+add_library(libothergood ${CMAKE_CURRENT_BINARY_DIR}/libothergood.cpp)
+set_property(TARGET libothergood APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_BINARY_DIR}/othergood
+)
+
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/libgood.cpp // No content \n)
+add_library(libgood ${CMAKE_CURRENT_BINARY_DIR}/libgood.cpp)
+set_property(TARGET libgood APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES
+
${CMAKE_CURRENT_BINARY_DIR}/good;$TARGET_PROPERTY:libothergood,INTERFACE_INCLUDE_DIRECTORIES
+)
+
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/libbad.cpp // No content \n)
+add_library(libbad ${CMAKE_CURRENT_BINARY_DIR}/libbad.cpp)
+set_property(TARGET libbad APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_BINARY_DIR}/bad
+)
+
+
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/lib5.cpp #include \common.h\\n)
+add_library(lib5 ${CMAKE_CURRENT_BINARY_DIR}/lib5.cpp)
+
+# Assuming the link order must be:
+target_link_libraries(lib5 libbad libgood)
+
+# Oops!.
+# As include directory order and link order are the same when using
target_link_libraries, we have to
+# get the libgood includes in before the libbad includes.
+# We do that with this command:
+target_include_directories(lib5
+ BEFORE PRIVATE $LINKED:libgood
+)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77cecb778ff1882d87401c1055ec06585462f787
commit 77cecb778ff1882d87401c1055ec06585462f787
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Nov 5 12:43:28
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-556-g1638124
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 163812468054601c95ac894703a6299d3b324e22 (commit) from fc2638f0b43f88683b6d8251be92119f4a3b3f1b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=163812468054601c95ac894703a6299d3b324e22 commit 163812468054601c95ac894703a6299d3b324e22 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Feb 1 00:01:16 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Feb 1 00:01:16 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7e9cc40..188a3db 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130131) +set(CMake_VERSION_TWEAK 20130201) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
