[CMake] XCode generator and .metal shader files
Hi,
After adding a .metal file to a target via add_executable the metal file
does not get pushed to the generated project`s Compile Sources queue and
subsequently does not compile during project build unless I add the file to
the queue manually from Xcode, I`ve tried setting compile flags on the
.metal file as I`ve seen people mention that it works:
set(MetalTriangle_SHADERS Shaders.metal)
set_source_files_properties(${MetalTriangle_SHADERS} PROPERTIES
COMPILE_FLAGS "-fno-fast-math")
but unfortunately it did not help, is there any workaround to this problem?
--
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
[CMake] [ANNOUNCE] CMake 3.6.1 available for download
We are pleased to announce that CMake 3.6.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ * The CPack NSIS generator's configuration file template was fixed to quote the path to the uninstaller tool used by the "CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL" option. This avoids depending on an insecure Windows feature to run an uninstaller tool with a space in the path. Thanks for your support! - Changes in 3.6.1 since 3.6.0: Alex Turbov (1): CPack/RPM: Add missed CPACK_RPM_FILE_NAME fallback variable Brad King (6): Restore find_(library|file|path) search of PATH itself VS: Fix VS 2015 .vcxproj debug setting for v90 toolset (#15986) Ninja: Do not force response files when no sysconf(3) limit is used CPack: Add compatibility for incorrect CPACK_INSTALL_CMAKE_PROJECTS value Autogen: Revert changes to generate moc/rcc in subdirectories CMake 3.6.1 Chuck Atkins (3): FindHDF5: Fix h5cc arg parsing to work with homebrew on Mac FindHDF5: Properly fail when required components are not found. FindHDF5: Cleanup inconsistent use of HDF5_ROOT Justin Clift (1): NSIS: Quote uninstaller path when executing it in a shell -- 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
[CMake] Ninja generator bug when handling Windows .dll without associated import .lib
Hello, Apologies if this is a duplicate, I searched the net but was unable to find references to this bug. When a Windows .DLL is generated, the Microsoft linker may sometimes decide that no import library needs to be built. This happens often in one of our projects, we have many .dll's that tie themselves into our infrastructure during static class initialization and export no functions (although they do work and get called via class method pointers from elsewhere) The Ninja CMake generator seems to always emit a dependency on an associated import library along with the .dll file. This causes Ninja to think that a just-built .dll is out of sync (as it can't find the import library file) and relink it, even though it is not dirty. -- 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
[CMake] Ninja generator bug when handling Windows .dll without associated import .lib
Hello, Apologies if this is a duplicate, I searched the net to the best of my ability but was unable to find references to this bug. When a Windows .DLL is generated, the Microsoft linker may sometimes decide that no import library needs to be built. This happens often in one of our projects, we have many .dll's that tie themselves into our infrastructure during static class initialization and export no functions (although they do work and get called via class method pointers from elsewhere) The Ninja CMake generator seems to always emit a dependency on an associated import library along with the .dll file. This causes Ninja to think that a just-built .dll is out of sync (as it can't find the import library file) and relink it, even though it is not dirty. -- 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
