> On Jun 9, 2021, at 12:20 PM, Brennan Ashton <bash...@brennanashton.com> wrote: > > On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos <f.j.pa...@gmail.com> > wrote: > >> For me, cmake would be a no. >> The reasons are greatly outlined by Sebastien. >> >> However, I am not very experienced with it. (I just never liked it...) >> Are there any hard advantages that would justify such a migration? >> >> Are there things that can only be done in cmake, or that are so much easier >> that it is worth it? >> Does it have any special features that we need or definitely want? >> > > So for me here is the short list: > > The builds a much much faster especially for incremental builds. This is > even more true for non Linux environments. This is a big deal for testing > as well as for the individual developer. > > We continue to have to handle issues around OS specific things for paths > and scripting tools. For some of this we currently have to carry custom > tools to help and those tools are not know outside of the project. > > Some of our custom tools like mkdeps fall short especially when trying to > integrate third party libraries. We can continue to invest in our tools > here or use things that already exist and are well tested. This has been a > huge pain getting things like LTP integrated to improve our testing. > > IDE support. While you can certainly use and IDE with NuttX at it exists > today, it is not aware of the build system in any reasonable way which does > make integration harder. > > Management of build settings and overrides. These are possible today but > much harder to keep consistent across all the different builds as we > continue to see. > > > That all said if people are not onboard it's not worth half doing. I have > been supportive, but I do not want to push this on people.
Isn’t it possible to try CMake before completely moving over to it? This way people new to CMake can give it a try, play with it, and become familiar with it before rejecting it. I think both make system can coexist, but if not, then offer CMake as a top-level patch, i.e. Switch-to-CMake.patch that’s applied to the NuttX top level tree. I’m not suggesting this as a permanent mechanism, just during the test-before-transition stage. Assumption: I don’t believe anyone is suggesting changing or eliminating KConfig. Am I right? As I see it, CMake would adopt and eliminate a number of pernicious problems with the existing gmake build system. Here are a few: The “C” is for Cross-platform, it’s designed to manage host OS and target differences Windoze filename conventions and variations: Windoze native, Cygwin, etc. The use of gmake’s functions, especially “foreach” makes it difficult [impossible?] to properly and completely capture dependancies in a way that works for parallel builds. In any case, we haven’t yet succeeded in getting parallel builds to work correctly (they sometimes work). It supports multiple generators like Xcode, Eclipse, Visual Studio, etc. For many people new to CMake, CMake is different, and for that reason alone it’s bad. The first few times I had to use it, I hated it. While I can’t say I love it [yet?], I have come to appreciate it. I believe that once it’s implemented, people will realize its value in removing the multi-platform headaches and fewer build system breakages. Just my $0.025.
