Re: [cmake-developers] Review Request: Topic ExternalProject-independent-step-targets
On 12/16/2013 09:23 AM, Daniele E. Domenichelli wrote: After some tests I managed to reproduce the behaviour in this test that fails, both with ninja (always) and with make -j2 (only sometimes), but I'm no longer sure if this is a bug or not. [snip] The problem seems to be that the file level dependency is not set, if I add: add_custom_command(APPEND OUTPUT ${CMAKE_BINARY_DIR}/CMakeFiles/Proj2-step-stamp DEPENDS Proj1) the dependency issue is fixed. So maybe this is just a bug in this CMake code and not in CMake. Nonetheless I think it should be possible to do something like add_dependencies(Proj2-step Proj1) for targets created with ExternalProjects without caring about file level dependencies... what do you think? Maybe adding a function ExternalProject_Add_Dependencies(name step targets) that internally calls both add_dependencies and add_custom_command(APPEND)? Yes, I think that makes sense. Perhaps ExternalProject_Add_Step_Dependencies ? -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] define_property deprecated?
On 12/12/2013 01:19 PM, Matthew Woehlke wrote: There is some dependency logic that uses custom target properties under the hood. Right now I am using define_property to declare those. Should I (can I) not do that? I don't think there is any reason to use define_property except to mark a directory property as INHERITED into subdirectories. IIRC the command was created in case we wanted to document properties in CMake module code instead of builtin C++ DefineProperty calls. That never really happened and with the new documentation system it is never needed. Loosely related: is there a way to make export() and install(EXPORT) set these properties for exported targets? Not of which I'm aware. You can have your package configuration file add them after loading the imported targets, but that would be a (centralized) workaround. -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] documenting a CMake 'use' file
On 12/10/2013 04:57 PM, Matthew Woehlke wrote: Thanks. Are there any guidelines on documenting the parameters of CMake functions/macros? I didn't see that in the mentioned document. No convention has been established so there is none to document yet. We can see if any dominant form emerges. * ``VAR``: Output variable into which the result will be placed. * ``SEP``: String used to join adjacent tokens. * ``ARGN``: Tokens to be joined. I suggest using a definition list instead. Related; is there a way to turn a CMake module file (that is outside of CMake's module directory) into (e.g. HTML) documentation? No, and I don't want there to be a way to do this with cmake. It will limit our ability to refactor the internal document generation in the future. If someone wants to take code from Utilities/Sphinx and distribute a separately maintained project specifically to support this use case then that is possible. I just don't want to restrict modifications to documentation formatting and tools in our own source tree for compatibility with external documents. One of the reasons for using Sphinx is to avoid making CMake a documentation tool. -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] Misleading documentation for list(APPEND ....) signature
On 12/17/2013 08:52 PM, Alan W. Irwin wrote: The documentation says list(APPEND list element [element ...]) That should be changed to list(APPEND list [element ...]) This was already done recently: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eec7834e -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] documenting a CMake 'use' file
On 12/10/2013 04:46 PM, Matthew Woehlke wrote: Why is the copyright notice *after* the documentation? In the old documentation system the extractor only supported docs in the leading comment so the notice *had* to be later. Now it is just a convention. -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] documenting a CMake 'use' file
On 2013-12-18 11:52, Brad King wrote: On 12/10/2013 04:46 PM, Matthew Woehlke wrote: Why is the copyright notice *after* the documentation? In the old documentation system the extractor only supported docs in the leading comment so the notice *had* to be later. Now it is just a convention. Can we change that? :-) ...or at least change the documentation to make it clear that it is a convention and not / no longer mandatory? (For UseShiboken.cmake, I'm going to leave the copyright first... if that means the doc - which is RST anyway - can only be extracted with CMake ≥ 3.x, then that'll just have to do ;-). I'm not comfortable with the leading doc effectively hiding the copyright statement and wouldn't be in the least surprised if upstream were to reject having it follow the initial doc.) Thanks for the clarification, -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] documenting a CMake 'use' file
On 2013-12-18 11:52, Brad King wrote: On 12/10/2013 04:57 PM, Matthew Woehlke wrote: Thanks. Are there any guidelines on documenting the parameters of CMake functions/macros? I didn't see that in the mentioned document. No convention has been established so there is none to document yet. We can see if any dominant form emerges. * ``VAR``: Output variable into which the result will be placed. * ``SEP``: String used to join adjacent tokens. * ``ARGN``: Tokens to be joined. I suggest using a definition list instead. Like this? :``GENERATE_FLAGS``: (List) Additional options to pass to Shiboken. That's what I ended up using... maybe should have followed up to mention that :-). Thanks. Related; is there a way to turn a CMake module file (that is outside of CMake's module directory) into (e.g. HTML) documentation? No, and I don't want there to be a way to do this with cmake. It will limit our ability to refactor the internal document generation in the future. Does this mean one cannot e.g. use the CMake extensions and/or link to topics in CMake's documentation (provided a known location of the same)? Maybe it would help if I rephrase the question: I have a CMake module that is going to be provided by another project (i.e. will not live in the CMake repository). It has RST documentation. I would like to be able to generate HTML from that. How would you recommend to do so? I expect this is going to be not an unusual problem... -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014655]: Setting CMAKE_JAVA_TARGET_OUTPUT_DIR does not set the output for NMake type generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14655 == Reported By:Steve Wolak Assigned To: == Project:CMake Issue ID: 14655 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-18 15:13 EST Last Modified: 2013-12-18 15:13 EST == Summary:Setting CMAKE_JAVA_TARGET_OUTPUT_DIR does not set the output for NMake type generator Description: Setting CMAKE_JAVA_TARGET_OUTPUT_DIR to the desired output path seems to have no affect when using NMake as the generator. Steps to Reproduce: include(UseJava) set(CMAKE_JAVA_TARGET_OUTPUT_DIR insert your preferred dir here) add_jar(add your sources) The jar will continue to be placed into the current binary directory. According to documentation: The default OUTPUT_DIR can also be changed by setting the variable CMAKE_JAVA_TARGET_OUTPUT_DIR. Additional Information: This appears to be happening because of the use of cmake_parse_arguments in UseJava.cmake. _add_jar_OUTPUT_DIR is setup correctly with CMAKE_JAVA_TARGET_OUTPUT_DIR until that is called. As there is a work around for this (using OUTPUT_DIR in the add_jar command), I logged it as minor. == Issue History Date ModifiedUsername FieldChange == 2013-12-18 15:13 Steve WolakNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014656]: FindOpenMP does not return Fortran flags
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14656 == Reported By:Nicolas Bock Assigned To: == Project:CMake Issue ID: 14656 Category: Modules Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-18 16:44 CST Last Modified: 2013-12-18 16:44 CST == Summary:FindOpenMP does not return Fortran flags Description: The FindOpenMP modules assumes C/C++ code. For a pure Fortran project this is not very useful, as the C/C++ compiler flags don't always translate, or are not determinable because only a Fortran frontend of the compiler is installed. Ideally the module checks for OpenMP flags only for the languages the project is configured for. == Issue History Date ModifiedUsername FieldChange == 2013-12-18 16:44 Nicolas Bock New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014658]: project() resets CMAKE_VERBOSE_MAKEFILE
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14658 == Reported By:jschroeder Assigned To: == Project:CMake Issue ID: 14658 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-18 22:41 EST Last Modified: 2013-12-18 22:41 EST == Summary:project() resets CMAKE_VERBOSE_MAKEFILE Description: This may be OS and generator independent. (I've reproduced it on Windows 7 (with MS Visual Studio) and Ubuntu 12.04 (with GNUmake/GCC).) Using project() in a CMakeLists.txt file causes CMAKE_VERBOSE_MAKEFILE to be 0/False Steps to Reproduce: 1. Run cmake on the following (minimal) CMakeLists.txt file. Result: in the cmake output, the second message reporting the value of CMAKE_VERBOSE_MAKEFILE is FALSE. (See output below.) Expected result: in the cmake output, both lines reporting CMAKE_VERBOSE_MAKEFILE should be 1 (or True) begin CMakeLists.txt== cmake_minimum_required(VERSION 2.8.12) # I'm not sure how far back this bug might go set(CMAKE_VERBOSE_MAKEFILE 1) message(STATUS CMAKE_VERBOSE_MAKEFILE ${CMAKE_VERBOSE_MAKEFILE}) project(dummy) message(STATUS CMAKE_VERBOSE_MAKEFILE ${CMAKE_VERBOSE_MAKEFILE}) end CMakeLists.txt== foobar@ubuntu:~/build$ cmake .. -- CMAKE_VERBOSE_MAKEFILE 1 -- The C compiler identification is GNU 4.6.3 -- The CXX compiler identification is GNU 4.6.3 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- CMAKE_VERBOSE_MAKEFILE FALSE -- Configuring done -- Generating done -- Build files have been written to: /home/foobar/build == Issue History Date ModifiedUsername FieldChange == 2013-12-18 22:41 jschroeder New Issue 2013-12-18 22:41 jschroeder File Added: CMakeLists.txt == -- 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