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? If it takes X amount of time to migrate, will we gain more than X time of reduced maintenance? And when? Or will it make working with the project so much more enjoyable, for enough people, that at least pays off this way? Στις Τετ, 9 Ιουν 2021 στις 5:43 μ.μ., ο/η Alexander Vasiliev < alexvasil...@gmail.com> έγραψε: > > > > Maintaining two build systems in parallel does not really make sense to > > me. There should be only one and used and maintained by the community. > > > > We cannot get rid of the make in one commit. If we want CMake, it should > grow alongside the make. > > > ср, 9 июн. 2021 г. в 14:32, Ken Pettit <petti...@gmail.com>: > > > My opinion: > > > > CMake is horrible. Don't do it. It's hard to use for beginners, and > > hard to use for anyone who isn't just a strong advocate for it. > > > > Just my opionion. > > Ken > > > > > > On 6/9/21 6:46 AM, Gregory Nutt wrote: > > > I think that there a lot of people like myself who are opposed to the > > > CMake change but are remain silent to let the community make the > > > decision. I suspect that the advocates of CMake are having a larger > > > voice in the decision. > > > > > > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote: > > >> Hello, > > >> > > >> I believe in a stong principle, applied successfully numerous time in > > >> my embedded development company: > > >> > > >> > > >> It it's not broken, dont fix it. > > >> > > >> > > >> That applies precisely to this change. > > >> > > >> The build system we have have the following characteristics > > >> > > >> -it works for its intended purposes > > >> > > >> -it is pretty complex > > >> > > >> -ALL USERS have become used to it > > >> > > >> > > >> Changing it > > >> > > >> - will bring a lot of new bugs > > >> > > >> - along with the annoying feeling that these bugs were not necessary > > >> in the first place > > >> > > >> - No one will understand the build system anymore > > >> > > >> - since makefiles are now generated, we rely on yet another external > > >> tool with bugs in itself, and its idiosyncrasies and workarounds. > > >> > > >> > > >> Moreover: > > >> > > >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of > > >> the nuttx documentation will become fully obsolete overnight. > > >> > > >> > > >> Gratuitous changes are a hell, they destroy efficiency. > > >> > > >> They tend to appear more frequently in open source projects, because > > >> anyone can bring it change without a single damn given to customer > > >> since the code has no warranty of fitness of etc etc open source > > >> legalese. > > >> > > >> > > >> If it was me, I would not do this change. If I had to take a decision > > >> about something similar in my company, it would be a strong no. > > >> > > >> > > >> Sebastien > > >> > > >> > > >> Le 09/06/2021 à 14:57, Matias N. a écrit : > > >>> Hi everyone, > > >>> > > >>> this thread has received little engagement from the community > > >>> in general, for a change with such impact on daily use of NuttX > > >>> for everyone. > > >>> > > >>> While there was positive feedback on GH and a few people have > > >>> expressed more interest, not much has really happened. Meanwhile, > > >>> the backlog of changes that would need to be backported continues > > >>> to increase. > > >>> > > >>> At the same time, I see many PRs addressing subtle issues with > > >>> current build system, which are mostly already solved with the > > >>> migration > > >>> to CMake. So there's continued effort in maintaining the current > system > > >>> which could be in part dedicated to the migration to a better system. > > >>> > > >>> I have offered technical guidance on testing and extending to other > > >>> platforms and also to add base support for other arch's so that the > > >>> focus > > >>> can be put mostly at the board level and on test and validation on > > >>> different > > >>> platforms and target hardware. However, after having worked on this > > >>> for more than a month I feel this is not really picking up the > > >>> interest it > > >>> requires for proper adoption by the community. > > >>> > > >>> Maybe the proper approach would be to call on a vote (*) > > >>> for this feature to have explicit support from the community and > > >>> ensure involvement from others than me to move forward. > > >>> Otherwise, or if the vote does not pass, I will not be pushing > > >>> forward with this. > > >>> > > >>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally > > >>> call on > > >>> a vote and what the exact procedure is, but maybe other PPMC member > > >>> can do so. > > >>> > > >>> Best, > > >>> Matias > > >>> > > >>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote: > > >>>> I am interested and I'll try to help with boards I can test. It > > >>>> will take a > > >>>> few days to get around to it because this has been a busy month, > > >>>> but I'm > > >>>> catching up. > > >>>> > > >>>> Cheers > > >>>> Nathan > > >>>> > > >>>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis > > >>>> <acas...@gmail.com <mailto:acassis%40gmail.com>> > > >>>> wrote: > > >>>> > > >>>>> I think we can divide the effort to port all the boards to the new > > >>>>> CMake. > > >>>>> > > >>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2. > > >>>>> > > >>>>> Let see if we get more people involved in this effort. > > >>>>> > > >>>>> BR, > > >>>>> > > >>>>> Alan > > >>>>> > > >>>>> On 6/1/21, Matias N. <mat...@imap.cc <mailto:matias%40imap.cc>> > > >>>>> wrote: > > >>>>>> Hi, > > >>>>>> just wanted to add that until this is ready, the gap between > > >>>>>> master and > > >>>>> the > > >>>>>> branch > > >>>>>> widens with every merged PR and this increases the backporting > > >>>>>> effort. > > >>>>>> I'm willing to do most of the remaining work but as I mentioned I > > >>>>>> cannot > > >>>>>> possibly test everything so > > >>>>>> help is needed. > > >>>>>> I'd really like your feedback on this before I continue and > > >>>>>> ensure the > > >>>>>> effort will not go to waste. > > >>>>>> > > >>>>>> Best, > > >>>>>> Matias > > >>>>>> > > >>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote: > > >>>>>>> Hi, > > >>>>>>> for anyone not following the relevant PR, please have a look at > the > > >>>>>>> current state here: > > >>>>>>> > > >>>>>>> https://github.com/apache/incubator-nuttx/pull/3704 > > >>>>>>> > > >>>>>>> This is now at a point where it can be tested by others. It > > >>>>>>> would be > > >>>>> very > > >>>>>>> good to get some > > >>>>>>> help testing what I got so far (sim and stm32f4discovery, both > > >>>>>>> on Linux > > >>>>>>> and mac), by running > > >>>>>>> examples and test. There are some brief instructions at the end > > >>>>>>> of the > > >>>>> PR > > >>>>>>> description for building. > > >>>>>>> > > >>>>>>> Other than that, I can continue porting other arch's and boards > > >>>>>>> with the > > >>>>>>> help of CI but it would be > > >>>>>>> best if others with more boards could help testing (and ideally > > >>>>>>> with > > >>>>> some > > >>>>>>> PRs, as the hard part > > >>>>>>> is mostly done) those as well. > > >>>>>>> > > >>>>>>> Also, note that this is a PR against a branch so we could > > >>>>>>> eventually > > >>>>> merge > > >>>>>>> it before adding support > > >>>>>>> for other arch/boards. And finally, I will provide documentation > > >>>>>>> to the > > >>>>>>> new build system in a separate > > >>>>>>> PR at some point, which I hope will ease the transition and help > > >>>>>>> reviewing. > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> Matias > > >>>>>>> > > >>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote: > > >>>>>>>> A new issue is opened recently to address this topic: > > >>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455 > > >>>>>>>> This proposal has the depth of the impact in our daily working, > > >>>>>>>> so it's > > >>>>>>>> very important to get the feedback from the community before > > >>>>>>>> the real > > >>>>>>>> action is taken. > > >>>>>>>> If you have any concern or suggestion, please reply to this > email. > > >>>>>>>> > > >>>>>>>> Thanks > > >>>>>>>> Xiang > > >>>>>>>> > > > > > > > >
