Re: [cmake-developers] CodeLite generator enhancement(s)
Alright I'm going to try this again. Removed the clone I had, made a new one. Going to address all the points the CI issues again & undo c++11 Minze On Sat, Sep 17, 2016 at 11:37 AM, Minze Zwerver wrote: > Okay got it pushed. > > That bot sure is a .. > I made a pull request, fixed it's remarks. And it's still not happy. > > > On Fri, Sep 16, 2016 at 2:49 PM, Brad King wrote: > >> On 09/16/2016 05:49 AM, Minze Zwerver wrote: >> > I can't commit to the gitlab , it says something regarding no disk >> space. >> >> Bad luck ;) >> >> I've notified our admins. Please try again in a few hours. >> >> -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] Use of C++11 in CMake's own source code
That was my merge request. Which didn't get accepted anyway. I'm currently starting a new clone to address all the points the CI had. But after reading this I'll also remove the C++11 stuff. Minze On Tue, Sep 20, 2016 at 5:30 PM, Brad King wrote: > On 09/20/2016 11:12 AM, Craig Scott wrote: > > some C++11 stuff in at least one recent merge request > > We allow C++14 in code guarded by HAVE_SERVER_MODE because that is > a new/optional feature that doesn't have to work on all platforms yet. > > Everything not guarded by HAVE_SERVER_MODE needs to be able to compile > in all language levels C++98 and above. We have CM_NULLPTR and similar > macros to enable C++11 safety checks when building at that level or > above, but they fall back to C++98-compatible code too. > > -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 > -- 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] possible fix to include in release
Hi, If there is a CMake 3.6.3, I'd like to request the inclusion of https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c Some Linux distros are now shipping cmake-gui on top of Qt5, and the reported QFileDialog problem is present. See also http://public.kitware.com/pipermail/cmake/2016-September/064262.html Thanks, Clint -- 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] FastBuild Generator
On 09/22/2016 03:02 PM, Charles Huet wrote: > is linux/mac support mandatory also ? > Fastbuild does support those platforms, but the generator so far does > not work as well (or at all) on those platforms. I think it is okay to support only a subset of platforms at first. Please just make the generator error out early on a platform that is not supported, or simply not even compile on such hosts. 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] FastBuild Generator
> IIUC this refers to: > * http://fastbuild.org > * https://github.com/fastbuild/fastbuild Yes, exactly. >From a quick glance the main problem I see is that it doesn't follow the Makefile/Ninja generator model of organizing the generator code into a per-target generator. OK, so I need to make use of these. >We can do high-level reviews here first. Alright then. >Please make every commit properly formatted (with clang-format) rather than formatting after-the-fact. I actually remembered about the clang-format thread just before writing the first email, so I thought I should just quickly ut everything to format. >If you've made substantial non-formatting changes from the original >version please record yourself as the author and add a trailer to >the commit message I squashed everything into a big commit to make things easier for me, and completely forgot about proper attribution of the work, so I'll squash all of Josh's commits into one, and all of mine into another and make sure those are correctly formatted. To sum up, what I have to do now is: * squash commits and format those for proper attribuation * refactor to have a cmFastbuildTargetGenerator that inherits cmCommonTargetGenerator * get the tests to pass I guess before it gets fully integrated into CMake 100% test pass is mandatory, but is linux/mac support mandatory also ? Fastbuild does support those platforms, but the generator so far does not work as well (or at all) on those platforms. Best, Charles Le jeu. 22 sept. 2016 à 19:26, Brad King a écrit : > On 09/22/2016 10:41 AM, Charles Huet wrote: > > a Fastbuild generator in the works, whose development started on CMake > 3.2, > > and was pretty much abandonned for the past 5 months. > > > > I took the time to rebase it on master > > Thanks for reviving it. > > IIUC this refers to: > > * http://fastbuild.org > * https://github.com/fastbuild/fastbuild > > > big design issues can be caught right now > > From a quick glance the main problem I see is that it doesn't follow > the Makefile/Ninja generator model of organizing the generator code > into a per-target generator. See cmCommonTargetGenerator and its > subclasses. We've found that having a per-target generator is much > easier than passing the target pointers around in "local" generators. > > > Should I create a MergeRequest on gitlab? > > That will be fine when you have something ready, preferably after > addressing major architectural issues. We can do high-level reviews > here first. > > > https://github.com/packadal/CMake/tree/fastbuild-master > > Please make every commit properly formatted (with clang-format) > rather than formatting after-the-fact. > > If you've made substantial non-formatting changes from the original > version please record yourself as the author and add a trailer to > the commit message such as > > Co-Author: Josh Green > > or > > Inspired-by: Josh Green > > depending on how much original work remains. > > 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] FastBuild Generator
On 09/22/2016 10:41 AM, Charles Huet wrote: > a Fastbuild generator in the works, whose development started on CMake 3.2, > and was pretty much abandonned for the past 5 months. > > I took the time to rebase it on master Thanks for reviving it. IIUC this refers to: * http://fastbuild.org * https://github.com/fastbuild/fastbuild > big design issues can be caught right now >From a quick glance the main problem I see is that it doesn't follow the Makefile/Ninja generator model of organizing the generator code into a per-target generator. See cmCommonTargetGenerator and its subclasses. We've found that having a per-target generator is much easier than passing the target pointers around in "local" generators. > Should I create a MergeRequest on gitlab? That will be fine when you have something ready, preferably after addressing major architectural issues. We can do high-level reviews here first. > https://github.com/packadal/CMake/tree/fastbuild-master Please make every commit properly formatted (with clang-format) rather than formatting after-the-fact. If you've made substantial non-formatting changes from the original version please record yourself as the author and add a trailer to the commit message such as Co-Author: Josh Green or Inspired-by: Josh Green depending on how much original work remains. 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
[cmake-developers] FastBuild Generator
Hi, As some of you may know, there is a Fastbuild generator in the works, whose development started on CMake 3.2, and was pretty much abandonned for the past 5 months. I took the time to rebase it on master, and while there is a lot to clean up (and some stuff works worse that it used to because the rebase was done hastily), I'd like for a first step review to start, so that big design issues can be caught right now, instead of waiting for 100% of the tests to pass before re-writing most of the code. How does this process goes ? Should I create a MergeRequest on gitlab ? A Pull request on GitHub ? patches sent by mail ? So far the code lives in https://github.com/packadal/CMake/tree/fastbuild-master Thanks, Charles. FYI as of the rebase on CMake 3.6.1, the tests results are: 94% tests passed, 25 tests failed out of 400 Label Time Summary: Label1= 0.66 sec (1 test) Label2= 0.66 sec (1 test) Total Test time (real) = 614.33 sec The following tests FAILED: 37 - MSManifest (Failed) 46 - ObjectLibrary (Failed) 61 - Preprocess (Failed) 62 - ExportImport (Failed) 70 - StagingPrefix (Failed) 79 - Module.ExternalData (Failed) 109 - CustomCommand (Failed) 114 - BuildDepends (Failed) 115 - SimpleInstall (Failed) 116 - SimpleInstall-Stage2 (Failed) 132 - ExternalProject (Failed) 134 - ExternalProjectLocal (Failed) 135 - ExternalProjectUpdateSetup (Failed) 136 - ExternalProjectUpdate (Failed) 153 - Plugin (SEGFAULT) 156 - SubDir (Failed) 194 - CMakeCommands.target_link_libraries (Failed) 226 - InterfaceLinkLibraries (Failed) 275 - RunCMake.CMP0060 (Failed) 277 - RunCMake.CMP0065 (Failed) 280 - RunCMake.BuildDepends (Failed) 282 - RunCMake.Configure (Failed) 362 - RunCMake.ExternalProject (Failed) 369 - RunCMake.AutoExportDll (Failed) 400 - CMake.CheckSourceTree (Failed) -- 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] Security in CMake
The most of the functions could be overloaded. You could overload those functions, filter options out and pass the new options to the original function which starts with and '_' underscore. The most of the CMake module files could also be overloaded. Hope it helps Best regards Roman > Am 21.08.2016 um 10:24 schrieb Tobias Hunger : > > Hi Egor, > > Am 20.08.2016 23:42 schrieb "Egor Pugin" : > > You are right at many points. It's hard to really secure the system > > from build system/build artifacts/3rd party apps. > > But step by step it's possible to decrease number of potential sources > > of vulnerabilities. > > Retrofitting security into a product that was designed without any > consideration for security from the start is going to be hard. > > I do not know what you want to do, so I am not going to claim it is > impossible:-) > > > Described cmake features would be very helpful for this. > > Right now I'm just investigating possible security improvements and > > this is only 'nice-to-have' feature. > > What are the attack scenarios you want to defend against? What should not be > possible in your system that currently is in CMake? How do these steps help > in securing against those attacks? > > As a user of CMake I am very much opposed to disabling functionality based on > the context: That forces me to keep more state in my head when reading > CMakeLists.txt files. CMake does way too much in a way to obscure syntax > already! > > Best regards, > Tobias > > > On 21 August 2016 at 00:25, Tobias Hunger wrote: > > > Hi Egor, > > > > > > Am 20.08.2016 13:48 schrieb "Egor Pugin" : > > >> > > >> Hi, > > >> > > >> I'm working on a package manager based on cmake. > > >> And some cmake instructions are downloaded with user packages. > > >> I'd like to have an ability to deny some cmake features in such > > >> external untrusted insertions. > > > > > > I am no CMake expert, but you are talking about securing a program that is > > > meant to take arbitrary input and run user-defined commands on that to > > > produce possibly executable output. > > > > > > I do not see any safe subset of CMake commands that is still able to do > > > anything useful. > > > > > > I can see a way for "insertions" to be useful, that does not involve them > > > changing the configuration (e.g. for a cross compiler), involve running > > > some > > > 3rd party program (e.g. to add support for a new documentation system, > > > parser generator or whatnot), or the production of build artifacts (e.g. > > > build some library for the developer to use). > > > > > > *All* of these are inheritently unsafe. > > > > > > Configuration change: Change the C compiler to rm and pass force -rf -- / > > > as > > > flags. > > > > > > 3rd party program: Run rm -rf / when some certain input file is seen. > > > > > > Build artifacts: Put running rm -rf / into the binary/library so that this > > > is run during normal development workflow. > > > > > > I would try to run my package manager in an environment where running rm > > > -rf > > > is harmless to the overall system health. Virtual machines or containers > > > spring to mind there. Not sure that is feasible. > > > > > > Or come up with insertions signing, etc. so that users can at least know > > > they got what was uploaded and know whom to blame when their systems get > > > wiped. > > > > > > Beat Regards, > > > Tobias > > > > > > > > -- > > Egor Pugin > > -- > > 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 -- 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
