Re: [cmake-developers] Add native options to the clean step of 'cmake --build .. --clean-first'
On Fri, Dec 16, 2016 at 09:46:22 +0100, Yves Frederix wrote: > Although I am not fully convinced that the above might actually happen > in 'normal' practice, I do agree that it is a risk that should not be > introduced simply to get less verbose output for the clean step (my > use case). Pulling the PR ;) Thanks for your insights! If that is what you want, a `clean-quiet` target might be more useful which then uses generator-specific flags. This could even be a separate `--quiet` flag for `cmake --build` which would then apply to both the build and clean step. --Ben -- 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 native options to the clean step of 'cmake --build .. --clean-first'
> Flags for other generators can cause the `clean` to not actually happen. > For example, with make `cmake --build ... --clean-first -- -i` can cause > the clean to silently fail and then it isn't really a clean build. Or > the `-t` flag which skips running commands and instead just touches > output files. `-n` just prints what would be done. Or a target is passed > and so you effectively have `make clean -j10 mytarget; make -j10 > mytarget` which could be interesting with the `mytarget` subgraph making > files while `clean` is going around deleting them again. Although I am not fully convinced that the above might actually happen in 'normal' practice, I do agree that it is a risk that should not be introduced simply to get less verbose output for the clean step (my use case). Pulling the PR ;) Thanks for your insights! Regards, Yves > > IMO, these flags being passed to `--clean-first`'s subtask can > completely invalidate what is being asked for and it makes sense that > `--clean-first` is really just a plain clean. > > --Ben -- 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 native options to the clean step of 'cmake --build .. --clean-first'
On Wed, Dec 14, 2016 at 21:26:13 +0100, Yves Frederix wrote: > In PR https://gitlab.kitware.com/cmake/cmake/merge_requests/329 I am > suggesting to not only pass the additional/native build options to the > actual build step, but also to the 'clean' step in case of a call like > `cmake --build ... --clean-first`. The change is simple enough, but > there is the risk that a 'make clean' does not accept the additional > build options that for a normal build are ok, which could cause a > build to fail. Hence, I would like to check with the devs on this list > to judge the actual risk of this PR. > > Brad suggested to check the git logs to see if I could find something > there. I tracked things down to d35651fb in which the additional build > options were added.to the Build() function. It seems that already from > the beginning, the additional options were only passed to the build > step itself and not to the clean step. Whether there was a reason for > this is unclear from the logs. > > My question now is whether somebody remembers if there indeed was a > particular reason to leave out the additional options from the 'make > clean' call? And if not, could you come up with a real example in > which case the proposed change would cause a build failure? I have > tried, but wasn't able to come up with anything, although I must admit > that my view is limited as I do not have much experience with non-VS > generators. Flags for other generators can cause the `clean` to not actually happen. For example, with make `cmake --build ... --clean-first -- -i` can cause the clean to silently fail and then it isn't really a clean build. Or the `-t` flag which skips running commands and instead just touches output files. `-n` just prints what would be done. Or a target is passed and so you effectively have `make clean -j10 mytarget; make -j10 mytarget` which could be interesting with the `mytarget` subgraph making files while `clean` is going around deleting them again. IMO, these flags being passed to `--clean-first`'s subtask can completely invalidate what is being asked for and it makes sense that `--clean-first` is really just a plain clean. --Ben -- 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] Add native options to the clean step of 'cmake --build .. --clean-first'
Hi all, In PR https://gitlab.kitware.com/cmake/cmake/merge_requests/329 I am suggesting to not only pass the additional/native build options to the actual build step, but also to the 'clean' step in case of a call like `cmake --build ... --clean-first`. The change is simple enough, but there is the risk that a 'make clean' does not accept the additional build options that for a normal build are ok, which could cause a build to fail. Hence, I would like to check with the devs on this list to judge the actual risk of this PR. Brad suggested to check the git logs to see if I could find something there. I tracked things down to d35651fb in which the additional build options were added.to the Build() function. It seems that already from the beginning, the additional options were only passed to the build step itself and not to the clean step. Whether there was a reason for this is unclear from the logs. My question now is whether somebody remembers if there indeed was a particular reason to leave out the additional options from the 'make clean' call? And if not, could you come up with a real example in which case the proposed change would cause a build failure? I have tried, but wasn't able to come up with anything, although I must admit that my view is limited as I do not have much experience with non-VS generators. Thanks. Yves -- 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
