First, I would like to apologies to Matias for not being able to contribute
to the effort. We are working on the PX4 release, and a nuttx upgrade and I
just do not have the time to spare.
Ironically time is one of the things this discussion is all about. PR with
the current build system and CI take hours to complete.
Yes hours!
This may a not be an issue for the causal Nuttx contributor. For
maintainers it is a waste of time and money from their companies or
sponsors. It slows development progress down to a crawl.
This is one of the key reasons why we need Cmake, Nijabuild, and ccache
(and persistence).
I am reminded by the 'if it ain't broke..." statement of the proud
carpenter holding his hand saw, in hand, watching the guy cutting plywood
sheeting with a Skill Saw. Saying if it ain't broke....
That is the level of improvement that we are talking about. Yes but now you
need power on the job site…. Yes we have to overcome the barriers…
There are a lot of changes happening in NuttX. The immediate value versus
the level of effort to upgrade is difficult to see sometimes. For instance,
in building PX4 with master I have a PR with 666 some odd files changes
tracking the inttypes change and header file inclusion changes. While
typing PRI... thousands of times it is hard to remember that catching the
cause of a crash in the compiler, at build time is far superior to hours
spent in the debugger. The include file changes add proper partitioning
this is a code quality issue.
Sometimes it seems like syntactical sugar or gratuitous renaming changes
are just dumb. They are not. What is dumb is not sharing the sed script or
a text file with the key was/is changes as part of the release. That is on
us. Hats off to AlexanderVasiljev for his comments in [1]. We need to do
this more! No Really we do. Sharing the reasons for the change and how to
apply it to a derivative of NuttX will make NuttX more successful.
Cmake is not in that class of gratuitous changes. The advantage of 22
second out of tree NuttX build will be an obvious. Yes it is a new tool,
yes there is a learning curve, yes I hate cmake some times.
The level of effort for adoption is very high for NuttX. Getting to a
successful build is the first roadblock. Expecting contributors to find and
use buried tooling as opposed to top level commands just digs the hole
deeper.
Is anyone getting tiered of telling contributors "just run
./tools/checkpatch.sh -g HEAD~...HEAD" yet?
If the readme said:
Installing the Tools
Run tools/nuttxtools_install.sh
Building the code
make board-config
make board-config menuconfig|newconfig|saveconfig
Check formatting
make format
Getting to a successful build would be simple.
Cmake will help with this goal on all OS platforms. We just need to invest
in supporting Cmake. Rebasing it constantly is not an option it will
eventually need to be on master. We can keep make and cmake side by side if
we can find value in it.
One other thing I would like to say is PX4 went from make to Cmake years
ago now. It promoted adoption. I would never go back. Even hating cmake,
sometimes the benefits far out way the hassles.
>From that experience I can say it is important to do it right (refractor
with good design reviews of the user experience) and document it well. But
all the user has to type is `make board-config`
Regards,
David
[1] https://github.com/apache/incubator-nuttx/pull/3836#issue-660639554
-----Original Message-----
From: Matias N. [mailto:mat...@imap.cc]
Sent: Wednesday, June 09, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: [Discuss] Migrate the build system to CMake
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
>
