[cmake-developers] location tag substitution in external project BUILD_BYPRODUCTS
Hi, BUILD_BYPRODUCTS works very well with external projects and ninja :-) I'd like to propose a small enhancement: replace the location tags like BINARY_DIR by their real path in BUILD_BYPRODUCTS, in order to let the developer specify the byproducts without explicitly setting the external project binary dir. See the attached patch. Exposing _ep_replace_location_tags with a prettier name would also be nice. An example using that feature: https://github.com/glehmann/gtest-external/blob/byproduct-subst/gtest.cmake Thanks, Gaëtan 0001-replace-location-tags-in-external-project-byproducts.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 0015434]: Multiple add_custom_command with the same MAIN_DEPENDENCY causes duplicate rule invokations
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15434 == Reported By:Ben Boeckel Assigned To: == Project:CMake Issue ID: 15434 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-06 10:38 EST Last Modified: 2015-03-06 10:38 EST == Summary:Multiple add_custom_command with the same MAIN_DEPENDENCY causes duplicate rule invokations Description: Latest report: https://bugzilla.redhat.com/show_bug.cgi?id=1199360 AFAIK, I've only heard of this with the Unix Makefiles generator. Minimal test case wanted. == Issue History Date ModifiedUsername FieldChange == 2015-03-06 10:38 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
[cmake-developers] [CMake 0015432]: FindHDF5 HDF5_USE_STATIC_LIBRARIES should only apply to HD5 specific libraries
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15432 == Reported By:Sascha Kratky Assigned To: == Project:CMake Issue ID: 15432 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-03-06 08:01 EST Last Modified: 2015-03-06 08:01 EST == Summary:FindHDF5 HDF5_USE_STATIC_LIBRARIES should only apply to HD5 specific libraries Description: When HDF5_USE_STATIC_LIBRARIES is set to ON, i.e.: set (HDF5_USE_STATIC_LIBRARIES ON) find_package (HDF5) the module also links system libraries like libm, librt, libdl and libpthread statically. This does not work for shared libraries under Linux. The HDF5_USE_STATIC_LIBRARIES should only affect the linking of HDF5 related libraries libhdf5, libhdf5_hl libhdf5_cpp.a. == Issue History Date ModifiedUsername FieldChange == 2015-03-06 08:01 Sascha Kratky New 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
[cmake-developers] [CMake 0015433]: CPack WIX creates incorrect .wixobj filenames for CPACK_WIX_EXTRA_SOURCES
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15433 == Reported By:Mark Stijnman Assigned To: == Project:CMake Issue ID: 15433 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-06 08:08 EST Last Modified: 2015-03-06 08:08 EST == Summary:CPack WIX creates incorrect .wixobj filenames for CPACK_WIX_EXTRA_SOURCES Description: When using CPACK_WIX_EXTRA_SOURCES with filenames like MyProject.fragment1.wxs and MyProject.fragment2.wxs, in both cases the filename generated for the .wixobj file for the candle command is MyProject.wixobj, stripping both extensions. When you do this, the light command will therefore be trying to link MyProject.wixobj twice, leading to duplicate definition errors. Steps to Reproduce: Run the attached minimal test case, which includes two fragments that each define a single property, 'Fragment1Prop' and 'Fragment2Prop'. When you build the PACKAGE target, it will fail with an error error LGHT0091 : Duplicate symbol 'Property:Fragment2Prop' found. Additional Information: The solution is to change the call to cmSystemTools::GetFilenameWithoutExtension, in cmCPackWIXGenerator.cxx, line 274, to a call to cmSystemTools::GetFilenameWithoutLastExtension. A workaround currently is to just use a different naming convention, like MyProject_fragment1.wxs. == Issue History Date ModifiedUsername FieldChange == 2015-03-06 08:08 Mark Stijnman New Issue 2015-03-06 08:08 Mark Stijnman File Added: testcase.zip == -- 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] Extracting target metadata, IDE integration
On Wed, Mar 4, 2015 at 9:05 PM, Brad King brad.k...@kitware.com wrote: On 03/02/2015 09:10 PM, Aleix Pol wrote: I created a new version of the patch: http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Thanks. Samples: LLVM: https://paste.kde.org/pelr1ditp A small random KDE project: https://paste.kde.org/pgkbecv5p The location values need to be inside the configs elements because they can vary with the configuration in multi-config generators. Also the name location may not be specific enough. Some targets may have multiple output files (e.g. .dll, .lib). See the breakdown of $TARGET*FILE:... generator expressions: http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions Some set of values like that will be more useful. Good point, I changed it to use $TARGET_FILE:tgt. Showing a directory didn't make much sense anyway as we have more information with the full file path. If the the directory value is GetCurrentOutputDirectory, the build tree location of the project file, then that does not need to be per-configuration. In that case perhaps the name should be something like build_directory or project_directory. Used output_directory to match internal cmake naming. https://paste.kde.org/p5ogjqi2n https://paste.kde.org/puzgrgkzy And the new version of the patch (sorry my hosting seems down and I can't connect). https://paste.kde.org/pq0xungvq Aleix -- 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] Wrong behavior with 3.2.0-rc2
On 03/06/2015 10:22 AM, Pere Mato Vila wrote: Using version 3.2.0-rc2 on the Mac OS X 10.10 with the make generator. The following example executes the custom to create A.txt and B.txt twice when building with make -jN - cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) add_custom_target(Main ALL DEPENDS A.txt B.txt) add_custom_command(OUTPUT A.txt B.txt COMMAND touch A.txt COMMAND touch B.txt) - $ make clean $ make -j10 -- Configuring done -- Generating done -- Build files have been written to: /Users/mato/Development/ROOT/build.master/temp [100%] [100%] *Generating A.txt, B.txt* *Generating A.txt, B.txt* [100%] Built target Main This is not the case for version 3.1.3. This seems to be the case since [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with multiple custom command outputs (#15116) Nils -- 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] location tag substitution in external project BUILD_BYPRODUCTS
On 03/06/2015 09:17 AM, Gaetan Lehmann wrote: I'd like to propose a small enhancement: replace the location tags like BINARY_DIR by their real path in BUILD_BYPRODUCTS Good idea, thanks. I'll test the patch and integrate when I get a chance. -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] Wrong behavior with 3.2.0-rc2
On 03/06/2015 06:57 AM, Nils Gladitz wrote: On 03/06/2015 10:22 AM, Pere Mato Vila wrote: [100%] [100%] *Generating A.txt, B.txt* *Generating A.txt, B.txt* Thanks for trying the release candidate and reporting this. This seems to be the case since [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with multiple custom command outputs (#15116) Yes. I've re-opened the corresponding issue with a note about this: http://www.cmake.org/Bug/view.php?id=15116#c38168 Please follow that issue for further updates. We've already tagged v3.2.0 but it was not announced yet. It looks like 3.2.0 is DOA and we will have to skip to 3.2.1 to fix this. 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
