Hi, I'll answer a few question that came up several times about build systems co-existing. My previous answer was about co-existing them as a way to satisfy both set of users, which I don't think is the right approach. However, as a transition approach it does makes sense to me.
This is technically feasible however it will require adapting the Make based system as there were some changes needed to be made to Kconfig files, specifically this one: https://github.com/apache/incubator-nuttx/pull/3704/files?file-filters%5B%5D=.dat&file-filters%5B%5D=.pl&file-filters%5B%5D=.sh&file-filters%5B%5D=No+extension#diff-7c9693e9c5e61a1d80e09769377d47bb415ec39ca5aeaa85d13581b0105d6359 The main point is that CMake handles all steps related to build configuration (e.g. build flags based on optimization level) and platform detection. On master this is done via Kconfig (with settings which are stored in board defconfigs). One of these changes done to Kconfig is to pass the host-related variables as environment vars to Kconfig (so that it still possible to condition options based on platform). So, co-existing the build systems would require dealing with this, which I'm not sure how easy would be. With regards to comments about others requiring some hands-on time to become familiar with the system and try it for themselves: I agree with this point and was one of the reasons I actually started the migration. As I mentioned several weeks ago, the cmake branch can already be tested on the currently supported boards by everyone wishing to do so, but I don't think anyone really tried it as my offers about assistance in this were unanswered. Technical aspects aside: I do not wish to antagonize others not liking the change. I think I outlined the reasons I believe it is a positive change (and others did so as well) so now it is up to the community to decide what direction they wish to follow. In any case, if there's enough push forward, I would strongly recommend that this is explicitly decided via a vote (or any other mechanism considered appropriate) with a roadmap and organization, so that it becomes a goal for the NuttX project and not of just a subset of its community. I think this relates to making decisions about the project roadmap, which at some point needs to be done in an "official capacity". Best, Matias PS: the PR can always be reopened and the code lives on a branch on my fork. The branch on the repo does not yet contain anything, it simply acts as a stable base for the PR (and, of course, protects master from the merge, if it ever happens). On Wed, Jun 9, 2021, at 18:32, Nathan Hartman wrote: > On Wed, Jun 9, 2021 at 3:07 PM Matias N. <mat...@imap.cc > <mailto:matias%40imap.cc>> wrote: > > I will leave up to PPMC to decide whether a call to a vote is > > necessary/useful, but > > to me the community response is now quite clear. Also, voting based on > > majority > > would not really consider that such a change actually requires significant > > backing from the comunity. I will therefore will not continue working on > > this > > (you can delete the branch). > > Please don't delete the branch. > > Although switching build systems is a scary thought, I think we should > be open-minded about trying it. As I suggested before, and I think two > other people said something similar, perhaps the CMake can coexist > with the current Make build system somehow, even if it's labeled > "Experimental." Yes I know that creates more maintenance burden, and a > few people said it doesn't make sense to manage multiple build > systems, but other people pointed out that all downstream users will > need to rework their out-of-tree boards/frameworks/etc to adopt CMake. > That might make some people upset; but it will probably make some > people happy too, and we (or at least I) don't know which group is > bigger. In either case, with such a big change, I really think it > can't just happen in one atomic commit. For example, think of the > Python 2 -> Python 3 transition. That has been going on for how many > years now?! This proposed change won't take that long to transition, > but it will still need time. If we could have both build systems for a > while, it would allow people to test the waters with CMake but fall > back on Make if they hit problems and need to get their work done; it > will likely get a lot of feedback and fixes; and eventually depending > on how good it gets, we can deprecate Make and take CMake out of > "experimental" status. This is a disadvantage for maintenance, but it > will give downstream a transition period that will be needed for this > kind of change. > > In any event, whatever you do, please DON'T delete that branch! > > It would be better to find a way to merge it back to master without > destroying the existing Make system. > > That's just my two [insert 2/100 of your favorite currency here]. > > Nathan >
