[cmake-developers] [CMake 0015799]: Way to pass git options for cloning in ExternalProject_Add
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15799 == Reported By:gonzalob...@gmail.com Assigned To: == Project:CMake Issue ID: 15799 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-10-19 07:31 EDT Last Modified: 2015-10-19 07:31 EDT == Summary:Way to pass git options for cloning in ExternalProject_Add Description: AFAIK there is no way to pass git options while cloning repositories with ExternalProject_Add. Cloning git repositories can take a very long time. Git has options that make cloning instantaneous if e.g. only one revision is required. For example: --depth 1 clones only the latest revision very fast. I would like to be able to pass options to git clone since that would significantly improve my build times, which right now spend a very long time cloning the whole history of multiple git repositories. == Issue History Date ModifiedUsername FieldChange == 2015-10-19 07:31 gonzalobg88@gmail.comNew 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
Re: [cmake-developers] [Review Request] New module: IncludeUrl
Hello Brad, On 12/10/2015 17:00, Brad King wrote: >> I understand this is a quite controversial module, but I would like to >> stress that this is something that can already be done using CMake just >> by executing file(DOWNLOAD) and include(), this module just makes it >> easy to do it. Whether this is a security issue or not is up to how this >> module is used. > > That makes sense, though I feel this may be a niche use case and would > prefer to hear more general interest. If there is interest then for > upstream rather than a module perhaps this could be built in to the > include() command. Apparently there is no interest in this feature, therefore I'll withdraw my patch. Anyway, a hard coded solution would not work for me, since at the moment I'm stuck supporting CMake 2.8.9 and will not be able to use features from the next CMake version for a very long time. Cheers, Daniele -- 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 0015801]: FindCUDA.cmake incorrectly includes cu file dependencies
The following issue has been SUBMITTED.
==
https://cmake.org/Bug/view.php?id=15801
==
Reported By:tomwar
Assigned To:
==
Project:CMake
Issue ID: 15801
Category: Modules
Reproducibility:always
Severity: crash
Priority: normal
Status: new
==
Date Submitted: 2015-10-19 09:54 EDT
Last Modified: 2015-10-19 09:54 EDT
==
Summary:FindCUDA.cmake incorrectly includes cu file
dependencies
Description:
FindCuda.cmake line 399 include(${dependency_file}). Includes file that is
changed everytime during build process. Everytime when NVCC compiles some cu
file it generates new depends file (*_generated_*.cu.obj.depend) for it that
contains cu file dependencies (eg h files or other #included files). As I
checked in other cmake projects dependencies files (generate.stamp.depend)
contain only reference to other cmake fiels that it depends. I couldn't find
reference to source code files in generate.stamp.depend which makes sense. As
FindCuda adds such source code file dependency that is changed on compilation
time, it coused that after every build ZERO_CHECK triggers reconfiguration of
whole project which if you have enabled parallel build might coused crash of
MSBuild application or crash of build process b/c one thread is configuring
whole project and another is still compiling or linking different one. If in
other generate.stamp.depend files that were generated by cmake I couldn't find
any #included .h file dependency i would suggest to remove whole this
functionality from FindCUDA.cmake.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-10-19 09:54 tomwar 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
Re: [cmake-developers] Add command line options for deprecation message control
On 10/18/2015 07:59 AM, Michael Scott wrote: > I was thinking of coming back to issue of the deprecation and author > message options, now that CMake 3.4 has been released, is now a suitable > time for it? Yes. Early in the development cycle is best. > We modify cmake::IssueMessage to check the relevant CMake variables to > determine if the message should be output and at which level, we try to > get the script provided values if possible but handle the case where we > can't. cmake::IssueMessage does not have access to variables because it has no specific scope. It can only pay attention to global (cached) settings. I think having local CMAKE_WARN_DEPRECATED/CMAKE_ERROR_DEPRECATED vars can be left as specific to the message() command (and perhaps other IssueMessage callers as deemed appropriate per-case). Otherwise we should just have one global setting. > We also modify IssueMessage to use > cmSystemTools::SetFatalErrorOccured (or SetErrorOccured if that's > preferred) if a warning has been turned into an error. Finally we modify > the users of IssueMessage, to check the error occured state using > cmSystemTools, and use that to determine if an error has occured (rather > than the message level going into IssueMessage) and if the return value > should be changed accordingly. I realized we don't actually have to make warning=>error conversion immediately stop processing. We just need to make sure the process exit code is changed. We may not have to update all callers to achieve this; it would only be an optimization. OTOH perhaps we should defer this part until after the main warning control command-line options are worked out. 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] Filesystem timestamp checks
On 10/15/2015 03:58 PM, Ruslan Baratov wrote: > 3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt modification > time 105 > 4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is not > "newer" > then Makefile (105) there will be no regenerate command run and Makefile > remains the same > > Error can be easily reproduced on Apple HFS file system with unit = 1s (I hit > this problem doing changes even manually) but in general that's the "feature" > of native make tool + file system date resolution. Here is the similar test > for Linux with ext4: > Test: https://github.com/forexample/date-resolution-test > Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483 This is a fundamental limitation of buildsystems that use file timestamps. Your example shows that even plain "make" has this problem. One simply must use a workflow that does not involve changing files "immediately". It's not that bad. When manually entering commands it is very hard to type that fast. When scripting commmands the script can delay where needed. > There are a lot of scenarios where such problems can occurs, e.g. installing > files (reproducible on OSX and Linux): > * https://cmake.org/pipermail/cmake-developers/2015-October/026692.html This is a separate issue because it is about CMake truncating timestamps rather than the filesystem doing it. -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] CMakeForceCompiler
On 10/19/2015 10:46 AM, Brad King wrote: > CMakeForceCompiler: Deprecate this module and its macros > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6 After fixing a typo in the commit message: CMakeForceCompiler: Deprecate this module and its macros https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed77504d -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] CMakeForceCompiler
On 09/22/2015 04:39 PM, Brad King wrote: > I think it should be deprecated if possible. First we must > provide alternatives for all its use cases though. I'm not familiar with any cases that cannot be supported in other ways so I decided to deprecate the module now: CMakeForceCompiler: Deprecate this module and its macros https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6 This will at least call attention to the problems with this module and hopefully bring to light any remaining use cases that require it. -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] CMakeForceCompiler
On 10/19/2015 10:46 AM, Brad King wrote: > This will at least call attention to the problems with this > module and hopefully bring to light any remaining use cases > that require it. For reference, an additional problem is discussed here: https://cmake.org/Bug/view.php?id=15797#c39641 The try_compile calls in CMakeTestCompiler.cmake fail when extra sources, flags, or a linker file are needed for a specific architecture. -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] CMakeForceCompiler
Brad King wrote: > On 10/19/2015 10:46 AM, Brad King wrote: >> CMakeForceCompiler: Deprecate this module and its macros >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6 > > After fixing a typo in the commit message: > > CMakeForceCompiler: Deprecate this module and its macros > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed77504d You're using message(DEPRECATION) - no one will see the warning message you added. I think message(DEPRECATION) is broken by design and should not be used until it warns by default. I think we might have discussed that design choice at the time of adding it, but a brief search did not find it. Thanks, Steve. -- 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] CMakeForceCompiler
On 10/19/2015 03:02 PM, Stephen Kelly wrote: > You're using message(DEPRECATION) - no one will see the warning message you > added. At least now we can point at the documentation when someone asks about it. > I think message(DEPRECATION) is broken by design and should not be used > until it warns by default. We should fix that interface instead of declaring that it should never be used. There is active discussion in another thread about activating deprecation warnings: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13798/focus=14738 This could be raised over there. -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] Filesystem timestamp checks
On 19-Oct-15 19:30, Brad King wrote: On 10/15/2015 03:58 PM, Ruslan Baratov wrote: 3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt modification time 105 4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is not "newer" then Makefile (105) there will be no regenerate command run and Makefile remains the same Error can be easily reproduced on Apple HFS file system with unit = 1s (I hit this problem doing changes even manually) but in general that's the "feature" of native make tool + file system date resolution. Here is the similar test for Linux with ext4: Test: https://github.com/forexample/date-resolution-test Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483 This is a fundamental limitation of buildsystems that use file timestamps. Your example shows that even plain "make" has this problem. One simply must use a workflow that does not involve changing files "immediately". It's not that bad. When manually entering commands it is very hard to type that fast. When scripting commmands the script can delay where needed. I've already heard all this arguments and can only reply mine again :) * I've hit this while doing manual changes for Xcode project on Apple's HFS with 1s resolution * I don't want to patch every script. To be precise I prefer to "Fix something in one place so it works 100% and forget about it" then "Every time I start creating script I should remember that..." There are a lot of scenarios where such problems can occurs, e.g. installing files (reproducible on OSX and Linux): * https://cmake.org/pipermail/cmake-developers/2015-October/026692.html This is a separate issue because it is about CMake truncating timestamps rather than the filesystem doing it. Well yes, I was not very accurate with this statement, but in general it's very similar (if CMake truncation precision == file system date resolution then we have same situation) and "sleeping-guard" will fix it too. As I've mentioned I have a wrapper already so I've applied the "sleep" functionality there. It fix all issues of 1-3 test case, so this is closed for me now. Thanks, Ruslo -- 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
