> but to me the community response is now quite clear Is it? Six people on GitHub (+ some here?) provided positive feedback. While only one "hates it", and three more dislike it (mostly due to the huge undertaking and risk such a change requires).
As said, I am not experienced in cmake, to properly judge the decision. >From what I have seen here, I just do not consider the advantages as important enough. Personally, my "no" is not a hard one. On Wed, Jun 9, 2021, 23:09 David S. Alessio <david.s.ales...@gmail.com> wrote: > > > > 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. > > > > > >
