Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

On Mon, May 29, 2023 at 2:41 AM Michael Gielda  wrote:
>
> Haha, no worries, just subscribed on Friday for this particular reason :) 
> glad Renode was useful for EOS S3 and of course happy to see how we can 
> enable more of that.
>
>
> You mention you have a CI generating all the elfs, could you point me to 
> where that can be found? We could grab those and try to run them, see what 
> happens.
>
>

There is a giant bundle of the build artifacts that can be downloaded
here under linux-builds
https://github.com/apache/nuttx/actions/runs/5128284656
https://github.com/apache/nuttx/suites/13258933442/artifacts/723073966

For example there should be a stm32f4discovery/nsh with a nuttx.elf
which would be a small shell build for that board.

>From what I remember a few years ago was that I had to sub out some
clock and power related code to allow the target to boot, but I have
not tried in at least a year.

--Brennan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Tomek CEDRO]

On Wed, May 31, 2023 at 5:26 AM Brennan Ashton wrote:
> Still dropped him. Apparently I cannot use email correctly today...

Beware of big changes in quota handling at Google in recent days..
especially these using Workspace (Suite or whatever name it has now)..
I just got my email back to work after seeing that it went silent..
previous 30GB limit has been decreased to 15GB and all services
silently stopped (not even quota exceeded bounce message) until I
cleared the now common account storage.. so I did a backup and removed
everything.. now it will be easier to move away from Google o_O

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Michael Gielda]

Haha, no worries, just subscribed on Friday for this particular reason :)
glad Renode was useful for EOS S3 and of course happy to see how we can
enable more of that.


You mention you have a CI generating all the elfs, could you point me to
where that can be found? We could grab those and try to run them, see what
happens.


I can explain how we approach the platform generation we are doing for
Zephyr/U-Boot now to see how we could make it work for NuttX. Basically we
have this https://github.com/antmicro/dts2repl utility which uses the
Zephyr device trees generated with its build systems - with some
hand-written overlays (
https://github.com/antmicro/dts2repl/tree/main/dts2repl/overlay) which we
try to minimize / incorporate into the Zephyr device trees - into Renode's
repl files (platform files, the ones describing HW platforms). For the
simulation scenario, or .resc files, we have a template that's standard
across all platforms for a specific Zephyr demo. Same could be done for
NuttX of course.


Then we use this to run all the tests across all the platforms, and gather
and visualize the results.


If, when running NuttX (or any other payload) on those platforms we find
some of our platforms descriptions lacking some specific stuff like power
or clock management, we would add the necessary stuff into the overlays (or
Zephyr’s dts if possible)


I think some STM32 platforms would be a good entry point, since there are
many and they are pretty well supported in Renode/Zephyr/NuttX. But again,
if you point me to the elf files you are hosting, we could probably consume
them and report the results.


CCing my team to follow the conversation. They will have more details if
needed.


Best regards,

Michael


On Sat, 27 May 2023 at 01:01, Brennan Ashton 
wrote:

> Still dropped him. Apparently I cannot use email correctly today...
>
> On Fri, May 26, 2023, 3:40 PM Brennan Ashton 
> wrote:
>
>> Adding Michael back since I responded to him and he might not be on the
>> list...
>>
>> On Fri, May 26, 2023 at 3:23 PM Brennan Ashton
>>  wrote:
>> >
>> >
>> >
>> > On Fri, May 26, 2023, 3:11 PM Michael Gielda 
>> wrote:
>> >>
>> >> Hi Alan, nice to meet you Nathan,
>> >>
>> >> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
>> >> dashboard can be done and we assume would be useful. We just didn’t
>> get to
>> >> that as it would have been yet another research project (we are now
>> also
>> >> building a U-Boot dashboard, as we added 64-bit Cortex-A support -
>> >> https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as
>> well as
>> >> Cortex-R). But if there is interest, perhaps it’s worth revisiting the
>> idea.
>> >>
>> >> On our end, we base the simulation platform configuration on Zephyr,
>> so we
>> >> basically need a mapping of platforms in Nuttx to their “Zephyr names”
>> - we
>> >> can start of course with 1-2 and expand to more with time.
>> >>
>> >> Best regards,
>> >>
>> >> Michael
>> >
>> >
>> > Hey Michael,
>> > I actually had used renode when added upstream support a few years ago
>> with the QuickLogic EOS S3, and it was quite helpful.  That's when I talked
>> a bit about seeing if we could use it as a test platform here.
>> https://docs.google.com/presentation/d/1G1IKe3SjmB42eb7dhdoa4P_nREknsJy1/edit#slide=id.g9044e8e6ab_0_17
>> >
>> > One of the reasons I added support to export build artifacts in CI was
>> to enable having downstream stages that can pick up the already generated
>> elf.
>> >
>> > One thing at the time I hit with the targets I tested was some
>> assumptions around power and clock management that prevented NuttX from
>> booting (waiting for status bits usually).  So if we do go down this route
>> I suspect we will need to upstream some of those bits to the emulation
>> which I don't recall being too complicated.
>> >
>> > If people have a supported platform they would like to see I would be
>> happy to wire a proof of concept through.
>> >
>> > --Brennan
>>
>

-- 
Michael Gielda
mobile: +46 73 759 47 27
Antmicro AB | www.antmicro.com
Kistagången 16, 164 40 Kista, Sweden

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

Still dropped him. Apparently I cannot use email correctly today...

On Fri, May 26, 2023, 3:40 PM Brennan Ashton 
wrote:

> Adding Michael back since I responded to him and he might not be on the
> list...
>
> On Fri, May 26, 2023 at 3:23 PM Brennan Ashton
>  wrote:
> >
> >
> >
> > On Fri, May 26, 2023, 3:11 PM Michael Gielda 
> wrote:
> >>
> >> Hi Alan, nice to meet you Nathan,
> >>
> >> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
> >> dashboard can be done and we assume would be useful. We just didn’t get
> to
> >> that as it would have been yet another research project (we are now also
> >> building a U-Boot dashboard, as we added 64-bit Cortex-A support -
> >> https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as well
> as
> >> Cortex-R). But if there is interest, perhaps it’s worth revisiting the
> idea.
> >>
> >> On our end, we base the simulation platform configuration on Zephyr, so
> we
> >> basically need a mapping of platforms in Nuttx to their “Zephyr names”
> - we
> >> can start of course with 1-2 and expand to more with time.
> >>
> >> Best regards,
> >>
> >> Michael
> >
> >
> > Hey Michael,
> > I actually had used renode when added upstream support a few years ago
> with the QuickLogic EOS S3, and it was quite helpful.  That's when I talked
> a bit about seeing if we could use it as a test platform here.
> https://docs.google.com/presentation/d/1G1IKe3SjmB42eb7dhdoa4P_nREknsJy1/edit#slide=id.g9044e8e6ab_0_17
> >
> > One of the reasons I added support to export build artifacts in CI was
> to enable having downstream stages that can pick up the already generated
> elf.
> >
> > One thing at the time I hit with the targets I tested was some
> assumptions around power and clock management that prevented NuttX from
> booting (waiting for status bits usually).  So if we do go down this route
> I suspect we will need to upstream some of those bits to the emulation
> which I don't recall being too complicated.
> >
> > If people have a supported platform they would like to see I would be
> happy to wire a proof of concept through.
> >
> > --Brennan
>

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

Adding Michael back since I responded to him and he might not be on the list...

On Fri, May 26, 2023 at 3:23 PM Brennan Ashton
 wrote:
>
>
>
> On Fri, May 26, 2023, 3:11 PM Michael Gielda  wrote:
>>
>> Hi Alan, nice to meet you Nathan,
>>
>> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
>> dashboard can be done and we assume would be useful. We just didn’t get to
>> that as it would have been yet another research project (we are now also
>> building a U-Boot dashboard, as we added 64-bit Cortex-A support -
>> https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as well as
>> Cortex-R). But if there is interest, perhaps it’s worth revisiting the idea.
>>
>> On our end, we base the simulation platform configuration on Zephyr, so we
>> basically need a mapping of platforms in Nuttx to their “Zephyr names” - we
>> can start of course with 1-2 and expand to more with time.
>>
>> Best regards,
>>
>> Michael
>
>
> Hey Michael,
> I actually had used renode when added upstream support a few years ago with 
> the QuickLogic EOS S3, and it was quite helpful.  That's when I talked a bit 
> about seeing if we could use it as a test platform here. 
> https://docs.google.com/presentation/d/1G1IKe3SjmB42eb7dhdoa4P_nREknsJy1/edit#slide=id.g9044e8e6ab_0_17
>
> One of the reasons I added support to export build artifacts in CI was to 
> enable having downstream stages that can pick up the already generated elf.
>
> One thing at the time I hit with the targets I tested was some assumptions 
> around power and clock management that prevented NuttX from booting (waiting 
> for status bits usually).  So if we do go down this route I suspect we will 
> need to upstream some of those bits to the emulation which I don't recall 
> being too complicated.
>
> If people have a supported platform they would like to see I would be happy 
> to wire a proof of concept through.
>
> --Brennan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

On Fri, May 26, 2023 at 3:11 PM Michael Gielda  wrote:
>
> Hi Alan, nice to meet you Nathan,
>
> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
> dashboard can be done and we assume would be useful. We just didn’t get to
> that as it would have been yet another research project (we are now also
> building a U-Boot dashboard, as we added 64-bit Cortex-A support -
> https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as well as
> Cortex-R). But if there is interest, perhaps it’s worth revisiting the idea.
>
> On our end, we base the simulation platform configuration on Zephyr, so we
> basically need a mapping of platforms in Nuttx to their “Zephyr names” - we
> can start of course with 1-2 and expand to more with time.
>
> Best regards,
>
> Michael
>
Hey Michael,
I actually had used renode when adding upstream support a few years
ago with the QuickLogic EOS S3, and it was quite helpful.  That's when
I talked a bit about seeing if we could use it as a test platform
here.

One of the reasons I added support to export build artifacts in CI was
to enable having downstream stages that can pick up the already
generated elf.

One thing at the time I hit with the targets I tested was some
assumptions around power and clock management that prevented NuttX
from booting (waiting for status bits usually).  So if we do go down
this route I suspect we will need to upstream some of those bits to
the emulation which I don't recall being too complicated.

If people have a supported platform they would like to see I would be
happy to wire a proof of concept through.

--Brennan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

On Fri, May 26, 2023, 3:11 PM Michael Gielda  wrote:

> Hi Alan, nice to meet you Nathan,
>
> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
> dashboard can be done and we assume would be useful. We just didn’t get to
> that as it would have been yet another research project (we are now also
> building a U-Boot dashboard, as we added 64-bit Cortex-A support -
> https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as well as
> Cortex-R). But if there is interest, perhaps it’s worth revisiting the
> idea.
>
> On our end, we base the simulation platform configuration on Zephyr, so we
> basically need a mapping of platforms in Nuttx to their “Zephyr names” - we
> can start of course with 1-2 and expand to more with time.
>
> Best regards,
>
> Michael
>

Hey Michael,
I actually had used renode when added upstream support a few years ago with
the QuickLogic EOS S3, and it was quite helpful.  That's when I talked a
bit about seeing if we could use it as a test platform here.

One of the reason I added support to export build artifacts in CI was to
enable having downstream stages that can pick up the already generated elf.

One thing at the time I hit with the targets I tested was some assumptions
around power and clock management that prevented NuttX from booting
(waiting for status bits usually).  So if we do go down this route I
suspect we will need to upstream some of those bits to the emulation which
I don't recall being too complicated.

If people have a supported platform they would like to see I would be happy
to wire a proof of concept through.

--Brennan

>

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Michael Gielda]

Hi Alan, nice to meet you Nathan,

Indeed, we discussed with Alan some time ago, having a Nuttx-focused
dashboard can be done and we assume would be useful. We just didn’t get to
that as it would have been yet another research project (we are now also
building a U-Boot dashboard, as we added 64-bit Cortex-A support -
https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as well as
Cortex-R). But if there is interest, perhaps it’s worth revisiting the idea.

On our end, we base the simulation platform configuration on Zephyr, so we
basically need a mapping of platforms in Nuttx to their “Zephyr names” - we
can start of course with 1-2 and expand to more with time.

Best regards,

Michael


On Tue, 23 May 2023 at 16:42, Alan C. Assis  wrote:

> On 5/23/23, Brennan Ashton  wrote:
> > On Tue, May 23, 2023, 5:05 AM Nathan Hartman 
> > wrote:
> >
> >> On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
> >>  wrote:
> >> > I have also asked in the past about cutting down on the amount of
> >> > configs
> >> > we have checked in to be something like
> >> >
> >> > board:nsh -- only nsh and somewhat small
> >> > board:jumbo -- nsh, plus as many features as can fit and are
> >> > interesting
> >> in
> >> > the platform.
> >> >
> >> > For sim and some other targets it would make sense to have more
> >> > targets,
> >> > but not for every board.
> >>
> >>
> >> The idea of "board:jumbo" is very similar to what I was saying
> >> earlier. Maybe it will allow us to test fewer boards in less time but
> >> still get better test coverage. I am in favor of *better* test
> >> coverage, not less test coverage!!
> >>
> >> In the past, we talked about having some tests in CI for each PR, and
> >> then a bigger nightly test that builds all boards/configs like Greg
> >> used to do before releases. I don't think that ever happened, but ASF
> >> has a build farm separate from GitHub that we might use, or we could
> >> request from INFRA a virtual machine to set up a complete environment.
> >> Maybe that's something to think about.
> >>
> >
> >
> > I'm not sure why we would need anything new? We can still run this in
> > GitHub actions, but generally I don't think we should be having PRs merge
> > that are not passing build tests.
> >
> >
> > As for more testing of system on boards, QEMU is great for some tests and
> > there is a thin framework that does some of that work that Xiang and
> others
> > have started.  A few years ago I also gave a talk to see if there was
> > interest in working with the folks a renode.io. Their open source
> simulator
> > is what Zypher is using and at the time had minimal support, but check
> out
> > this awesome dashboard.
> >
> > https://zephyr-dashboard.renode.io/
> >
> >
> > It would be really cool if we could join forces a bit and continue to
> build
> > off that effort and improve some of the emulation as needed (some work is
> > required).
> >
>
> Some time ago I contacted Michael (from Antmicro, Renode. I CC he
> here) and he was very prone to help, but we didn't get a dashboard for
> NuttX yet.
>
> I totally agree with that idea, maybe we could create a page that will
> show up at nuttx-dashboard.renode.io this way they don't need to
> maintain it, since they already have much work with Zephyr.
>
> > Nothing will beat hardware, but as Xiang said let's start with the easy
> bit
> > which is software.
> >
>
> For sure! Let to start with QEMU/Renode and then will add real HW support.
>
> BR,
>
> Alan
>


-- 
Michael Gielda
mobile: +46 73 759 47 27
Antmicro AB | www.antmicro.com
Kistagången 16, 164 40 Kista, Sweden

RE: [OT] Learning Makefiles

[alin.jerpe...@sony.com]

Hi all,

I understand both arguments and I agree with both bunt unfortunately we can't 
maintain both environments so we will have to pick one.

I think that there is not much that we can do as PMC to pick 1 or the other 
option. An open vote to the community is probably the best but still limited in 
outreach and will still make some involved parts unhappy

There are many companies and projects that use NuttX with local code, sometimes 
extensively patches NuttX build environment to suit their needs. We should 
think about all the implications that tooling can have over their work since 
they are in the end the user.

Best regards
Alin

-Original Message-
From: Gregory Nutt  
Sent: den 23 maj 2023 16:29
To: dev@nuttx.apache.org
Subject: Re: [OT] Learning Makefiles

On 5/23/2023 7:32 AM, Nathan Hartman wrote:
> On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO  wrote:
>> On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
>>> Hello Tomek,
>>> Whatever is decided, the mere fact of wanting to make a decision on 
>>> this point will lead to more split.
>>> either from people that want cmake
>>> or from people who dont.
>>> this is an intrinsically bad decision Sebastien
>> I am afraid of that, trying to help to avoid that! :-(
>>
>> I know each group has its points.
>>
>> Maybe we should just see how it works out in practice?
>
> I very much *don't* want to cause a split in the community!!!
>
> We're only having a *discussion* and comparing/contrasting. We're not
> moving ahead and making any huge changes yet. I think it is a good
> thing for everyone to say their thoughts and explain pros/cons.
>
> If we try it in practice, we will definitely find out if it makes life
> better, or worse. Unfortunately that would require doing all the work
> (some is already done in PRs 3704 and 6718 but will need attention)
> and maintaining two parallel build systems for a while. Will people
> want to volunteer to do that if all the work might be thrown away?
> Maybe, maybe not. I suppose it depends on how strongly people feel
> about CMake.
>
> So I think, first, we should make a nice coherent list of pros/cons.
>
> I'm okay with tracking pros/cons in a GitHub issue instead of CWIKI.
>
> Cheers,
> Nathan

I see one of primary responsibility of the PMC is to support the needs a 
desires of the NuttX community.  For things like tools, the pros and 
cons are not nearly as important.  The easiest way to find out the will 
of the community is simply to ask, perhaps with a non-binding community 
vote.

On a different note, we have not talked about what level of testing a 
new build system should be held to.  I think that level should be quite 
high.  I don't think we should break any builds, even on an initial 
merge.  Satisfactory testing should address:

  * All build modes: FLAT, PROTECTED, KERNEL (including the kernel mode
file system)
  * All supported build platforms:  Linux, BSD, MacOS, Windows: Cygwin,
MYSYS, native. etc.  None of those should be broken.

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Xiang Xiao]

Here is the script to run the basic test:
https://github.com/apache/nuttx/blob/master/tools/ci/cirun.sh
Add a link in your config:
https://github.com/apache/nuttx/blob/master/boards/risc-v/qemu-rv/rv-virt/configs/citest/run
Build script will run it and report the result after the build pass:
https://github.com/apache/nuttx/blob/master/tools/testbuild.sh#L369C1-L380

On Wed, May 24, 2023 at 3:35 AM Nathan Hartman 
wrote:

> On Tue, May 23, 2023 at 10:06 AM Brennan Ashton
>  wrote:
> >
> > On Tue, May 23, 2023, 5:05 AM Nathan Hartman 
> > wrote:
> >
> > > On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
> > >  wrote:
> > > > I have also asked in the past about cutting down on the amount of
> configs
> > > > we have checked in to be something like
> > > >
> > > > board:nsh -- only nsh and somewhat small
> > > > board:jumbo -- nsh, plus as many features as can fit and are
> interesting
> > > in
> > > > the platform.
> > > >
> > > > For sim and some other targets it would make sense to have more
> targets,
> > > > but not for every board.
> > >
> > >
> > > The idea of "board:jumbo" is very similar to what I was saying
> > > earlier. Maybe it will allow us to test fewer boards in less time but
> > > still get better test coverage. I am in favor of *better* test
> > > coverage, not less test coverage!!
> > >
> > > In the past, we talked about having some tests in CI for each PR, and
> > > then a bigger nightly test that builds all boards/configs like Greg
> > > used to do before releases. I don't think that ever happened, but ASF
> > > has a build farm separate from GitHub that we might use, or we could
> > > request from INFRA a virtual machine to set up a complete environment.
> > > Maybe that's something to think about.
> > >
> >
> >
> > I'm not sure why we would need anything new? We can still run this in
> > GitHub actions, but generally I don't think we should be having PRs merge
> > that are not passing build tests.
> >
> >
> > As for more testing of system on boards, QEMU is great for some tests and
> > there is a thin framework that does some of that work that Xiang and
> others
> > have started.  A few years ago I also gave a talk to see if there was
> > interest in working with the folks a renode.io. Their open source
> simulator
> > is what Zypher is using and at the time had minimal support, but check
> out
> > this awesome dashboard.
> >
> > https://zephyr-dashboard.renode.io/
> >
> >
> > It would be really cool if we could join forces a bit and continue to
> build
> > off that effort and improve some of the emulation as needed (some work is
> > required).
>
>
> Wow, that is cool! I must have missed it when you mentioned it
> previously. Yes, this is something the NuttX project should look into.
>
> I agree with the QEMU idea as well, for those who want to build a
> test/development setup they can run locally.
>
> Both of these ideas are very good and we should pursue them. If we do
> QEMU, we should document it, or script it, or both, so that other
> community members can reproduce it and run a test system locally.
> Personally I would like such a setup, and I am interested in helping
> to document it.
>
> Cheers,
> Nathan
>

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Nathan Hartman]

On Tue, May 23, 2023 at 10:06 AM Brennan Ashton
 wrote:
>
> On Tue, May 23, 2023, 5:05 AM Nathan Hartman 
> wrote:
>
> > On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
> >  wrote:
> > > I have also asked in the past about cutting down on the amount of configs
> > > we have checked in to be something like
> > >
> > > board:nsh -- only nsh and somewhat small
> > > board:jumbo -- nsh, plus as many features as can fit and are interesting
> > in
> > > the platform.
> > >
> > > For sim and some other targets it would make sense to have more targets,
> > > but not for every board.
> >
> >
> > The idea of "board:jumbo" is very similar to what I was saying
> > earlier. Maybe it will allow us to test fewer boards in less time but
> > still get better test coverage. I am in favor of *better* test
> > coverage, not less test coverage!!
> >
> > In the past, we talked about having some tests in CI for each PR, and
> > then a bigger nightly test that builds all boards/configs like Greg
> > used to do before releases. I don't think that ever happened, but ASF
> > has a build farm separate from GitHub that we might use, or we could
> > request from INFRA a virtual machine to set up a complete environment.
> > Maybe that's something to think about.
> >
>
>
> I'm not sure why we would need anything new? We can still run this in
> GitHub actions, but generally I don't think we should be having PRs merge
> that are not passing build tests.
>
>
> As for more testing of system on boards, QEMU is great for some tests and
> there is a thin framework that does some of that work that Xiang and others
> have started.  A few years ago I also gave a talk to see if there was
> interest in working with the folks a renode.io. Their open source simulator
> is what Zypher is using and at the time had minimal support, but check out
> this awesome dashboard.
>
> https://zephyr-dashboard.renode.io/
>
>
> It would be really cool if we could join forces a bit and continue to build
> off that effort and improve some of the emulation as needed (some work is
> required).


Wow, that is cool! I must have missed it when you mentioned it
previously. Yes, this is something the NuttX project should look into.

I agree with the QEMU idea as well, for those who want to build a
test/development setup they can run locally.

Both of these ideas are very good and we should pursue them. If we do
QEMU, we should document it, or script it, or both, so that other
community members can reproduce it and run a test system locally.
Personally I would like such a setup, and I am interested in helping
to document it.

Cheers,
Nathan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Alan C. Assis]

On 5/23/23, Brennan Ashton  wrote:
> On Tue, May 23, 2023, 5:05 AM Nathan Hartman 
> wrote:
>
>> On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
>>  wrote:
>> > I have also asked in the past about cutting down on the amount of
>> > configs
>> > we have checked in to be something like
>> >
>> > board:nsh -- only nsh and somewhat small
>> > board:jumbo -- nsh, plus as many features as can fit and are
>> > interesting
>> in
>> > the platform.
>> >
>> > For sim and some other targets it would make sense to have more
>> > targets,
>> > but not for every board.
>>
>>
>> The idea of "board:jumbo" is very similar to what I was saying
>> earlier. Maybe it will allow us to test fewer boards in less time but
>> still get better test coverage. I am in favor of *better* test
>> coverage, not less test coverage!!
>>
>> In the past, we talked about having some tests in CI for each PR, and
>> then a bigger nightly test that builds all boards/configs like Greg
>> used to do before releases. I don't think that ever happened, but ASF
>> has a build farm separate from GitHub that we might use, or we could
>> request from INFRA a virtual machine to set up a complete environment.
>> Maybe that's something to think about.
>>
>
>
> I'm not sure why we would need anything new? We can still run this in
> GitHub actions, but generally I don't think we should be having PRs merge
> that are not passing build tests.
>
>
> As for more testing of system on boards, QEMU is great for some tests and
> there is a thin framework that does some of that work that Xiang and others
> have started.  A few years ago I also gave a talk to see if there was
> interest in working with the folks a renode.io. Their open source simulator
> is what Zypher is using and at the time had minimal support, but check out
> this awesome dashboard.
>
> https://zephyr-dashboard.renode.io/
>
>
> It would be really cool if we could join forces a bit and continue to build
> off that effort and improve some of the emulation as needed (some work is
> required).
>

Some time ago I contacted Michael (from Antmicro, Renode. I CC he
here) and he was very prone to help, but we didn't get a dashboard for
NuttX yet.

I totally agree with that idea, maybe we could create a page that will
show up at nuttx-dashboard.renode.io this way they don't need to
maintain it, since they already have much work with Zephyr.

> Nothing will beat hardware, but as Xiang said let's start with the easy bit
> which is software.
>

For sure! Let to start with QEMU/Renode and then will add real HW support.

BR,

Alan

Re: [OT] Learning Makefiles

[Gregory Nutt]

On 5/23/2023 7:32 AM, Nathan Hartman wrote:

On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO  wrote:

On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:

Hello Tomek,
Whatever is decided, the mere fact of wanting to make a decision on this
point will lead to more split.
either from people that want cmake
or from people who dont.
this is an intrinsically bad decision
Sebastien

I am afraid of that, trying to help to avoid that! :-(

I know each group has its points.

Maybe we should just see how it works out in practice?


I very much *don't* want to cause a split in the community!!!

We're only having a *discussion* and comparing/contrasting. We're not
moving ahead and making any huge changes yet. I think it is a good
thing for everyone to say their thoughts and explain pros/cons.

If we try it in practice, we will definitely find out if it makes life
better, or worse. Unfortunately that would require doing all the work
(some is already done in PRs 3704 and 6718 but will need attention)
and maintaining two parallel build systems for a while. Will people
want to volunteer to do that if all the work might be thrown away?
Maybe, maybe not. I suppose it depends on how strongly people feel
about CMake.

So I think, first, we should make a nice coherent list of pros/cons.

I'm okay with tracking pros/cons in a GitHub issue instead of CWIKI.

Cheers,
Nathan


I see one of primary responsibility of the PMC is to support the needs a 
desires of the NuttX community.  For things like tools, the pros and 
cons are not nearly as important.  The easiest way to find out the will 
of the community is simply to ask, perhaps with a non-binding community 
vote.


On a different note, we have not talked about what level of testing a 
new build system should be held to.  I think that level should be quite 
high.  I don't think we should break any builds, even on an initial 
merge.  Satisfactory testing should address:


 * All build modes: FLAT, PROTECTED, KERNEL (including the kernel mode
   file system)
 * All supported build platforms:  Linux, BSD, MacOS, Windows: Cygwin,
   MYSYS, native. etc.  None of those should be broken.

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

On Tue, May 23, 2023, 5:05 AM Nathan Hartman 
wrote:

> On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
>  wrote:
> > I have also asked in the past about cutting down on the amount of configs
> > we have checked in to be something like
> >
> > board:nsh -- only nsh and somewhat small
> > board:jumbo -- nsh, plus as many features as can fit and are interesting
> in
> > the platform.
> >
> > For sim and some other targets it would make sense to have more targets,
> > but not for every board.
>
>
> The idea of "board:jumbo" is very similar to what I was saying
> earlier. Maybe it will allow us to test fewer boards in less time but
> still get better test coverage. I am in favor of *better* test
> coverage, not less test coverage!!
>
> In the past, we talked about having some tests in CI for each PR, and
> then a bigger nightly test that builds all boards/configs like Greg
> used to do before releases. I don't think that ever happened, but ASF
> has a build farm separate from GitHub that we might use, or we could
> request from INFRA a virtual machine to set up a complete environment.
> Maybe that's something to think about.
>


I'm not sure why we would need anything new? We can still run this in
GitHub actions, but generally I don't think we should be having PRs merge
that are not passing build tests.


As for more testing of system on boards, QEMU is great for some tests and
there is a thin framework that does some of that work that Xiang and others
have started.  A few years ago I also gave a talk to see if there was
interest in working with the folks a renode.io. Their open source simulator
is what Zypher is using and at the time had minimal support, but check out
this awesome dashboard.

https://zephyr-dashboard.renode.io/


It would be really cool if we could join forces a bit and continue to build
off that effort and improve some of the emulation as needed (some work is
required).

Nothing will beat hardware, but as Xiang said let's start with the easy bit
which is software.

--Brennan

Re: [OT] Learning Makefiles

[Nathan Hartman]

On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO  wrote:
>
> On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
> > Hello Tomek,
> > Whatever is decided, the mere fact of wanting to make a decision on this
> > point will lead to more split.
> > either from people that want cmake
> > or from people who dont.
> > this is an intrinsically bad decision
> > Sebastien
>
> I am afraid of that, trying to help to avoid that! :-(
>
> I know each group has its points.
>
> Maybe we should just see how it works out in practice?


I very much *don't* want to cause a split in the community!!!

We're only having a *discussion* and comparing/contrasting. We're not
moving ahead and making any huge changes yet. I think it is a good
thing for everyone to say their thoughts and explain pros/cons.

If we try it in practice, we will definitely find out if it makes life
better, or worse. Unfortunately that would require doing all the work
(some is already done in PRs 3704 and 6718 but will need attention)
and maintaining two parallel build systems for a while. Will people
want to volunteer to do that if all the work might be thrown away?
Maybe, maybe not. I suppose it depends on how strongly people feel
about CMake.

So I think, first, we should make a nice coherent list of pros/cons.

I'm okay with tracking pros/cons in a GitHub issue instead of CWIKI.

Cheers,
Nathan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Tomek CEDRO]

On Tue, May 23, 2023 at 7:48 AM Xiang Xiao wrote:
> Why not start the test infrastructure from sim/qemu? It's more simple to
> set up and has unlimited resources. Once the sim/qemu test workflow is
> ready, it isn't very hard to duplicate to the real boards.

Yeah, *:nsh should work that way, and should allow some runtime tests on
various architectures that QEMU already provide :-)

https://www.qemu.org/docs/master/about/emulation.html

Emulation 

QEMU’s Tiny Code Generator (TCG) provides the ability to emulate a number
of CPU architectures on any supported host platform. Both System Emulation
 and User
Mode Emulation
 are
supported depending on the guest architecture.
Supported Guest Architectures for Emulation


Architecture (qemu name)

System

User

Notes

Alpha

Yes

Yes

Legacy 64 bit RISC ISA developed by DEC

Arm (arm, aarch64)

Yes


Yes

Wide range of features, see A-profile CPU architecture support

for details

AVR

Yes


No

8 bit micro controller, often used in maker projects

Cris

Yes

Yes

Embedded RISC chip developed by AXIS

Hexagon

No

Yes

Family of DSPs by Qualcomm

PA-RISC (hppa)

Yes

Yes

A legacy RISC system used in HP’s old minicomputers

x86 (i386, x86_64)

Yes


Yes

The ubiquitous desktop PC CPU architecture, 32 and 64 bit.

Loongarch

Yes

Yes

A MIPS-like 64bit RISC architecture developed in China

m68k

Yes


Yes

Motorola 68000 variants and ColdFire

Microblaze

Yes

Yes

RISC based soft-core by Xilinx

MIPS (mips*)

Yes


Yes

Venerable RISC architecture originally out of Stanford University

Nios2

Yes

Yes

32 bit embedded soft-core by Altera

OpenRISC

Yes


Yes

Open source RISC architecture developed by the OpenRISC community

Power (ppc, ppc64)

Yes


Yes

A general purpose RISC architecture now managed by IBM

RISC-V

Yes


Yes

An open standard RISC ISA maintained by RISC-V International

RX

Yes


No

A 32 bit micro controller developed by Renesas

s390x

Yes


Yes

A 64 bit CPU found in IBM’s System Z mainframes

sh4

Yes

Yes

A 32 bit RISC embedded CPU developed by Hitachi

SPARC (sparc, sparc64)

Yes


Yes

A RISC ISA originally developed by Sun Microsystems

Tricore

Yes

No

A 32 bit RISC/uController/DSP developed by Infineon

Xtensa

Yes


Yes

A configurable 32 bit soft core now owned by Cadence

A number of features are only available when running under emulation
including Record/Replay
 and QEMU TCG
Plugins
.
Semihosting


Semihosting is a feature defined by the owner of the architecture to allow
programs to interact with a debugging host system. On real hardware this is
usually provided by an In-circuit emulator (ICE) hooked directly to the
board. QEMU’s implementation allows for semihosting calls to be passed to
the host system or via the gdbstub.

Generally semihosting makes it easier to bring up low level code before a
more fully functional operating system has been enabled. On QEMU it also
allows for embedded micro-controller code which typically doesn’t have a
full libc to be run as “bare-metal” code under QEMU’s user-mode emulation.
It is also useful for writing test cases and indeed a number of compiler
suites as well as QEMU itself use semihosting calls to exit test code while
reporting the success state.

Semihosting is only available using TCG emulation. This is because the
instructions to trigger a semihosting call are typically reserved causing
most hypervisors to trap and fault on them.

Espressif adds their MCU support to qemu, they just added ESP32-C3 (RISC-V)

Re: [OT] Learning Makefiles

[Tomek CEDRO]

On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
> Hello Tomek,
> Whatever is decided, the mere fact of wanting to make a decision on this
> point will lead to more split.
> either from people that want cmake
> or from people who dont.
> this is an intrinsically bad decision
> Sebastien

I am afraid of that, trying to help to avoid that! :-(

I know each group has its points.

Maybe we should just see how it works out in practice?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Nathan Hartman]

On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
 wrote:
> I have also asked in the past about cutting down on the amount of configs
> we have checked in to be something like
>
> board:nsh -- only nsh and somewhat small
> board:jumbo -- nsh, plus as many features as can fit and are interesting in
> the platform.
>
> For sim and some other targets it would make sense to have more targets,
> but not for every board.


The idea of "board:jumbo" is very similar to what I was saying
earlier. Maybe it will allow us to test fewer boards in less time but
still get better test coverage. I am in favor of *better* test
coverage, not less test coverage!!

In the past, we talked about having some tests in CI for each PR, and
then a bigger nightly test that builds all boards/configs like Greg
used to do before releases. I don't think that ever happened, but ASF
has a build farm separate from GitHub that we might use, or we could
request from INFRA a virtual machine to set up a complete environment.
Maybe that's something to think about.

Cheers,
Nathan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Brennan Ashton]

On Mon, May 22, 2023, 12:14 PM Nathan Hartman 
wrote:

> On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet 
> wrote:
>
> >
> > If the untold reason is to speed up github tests, then run less tests.
> > Do we really need to test build on 13 or 20 arm platforms when only one
> > config of the other architectures is tested, and the actual value of
> > these build test is dubious?



My grumbles about build times it not about CI (although I would love for
the steps like clean to not be so slow).  I would be quite opposed to
letting PRs through without passing current build tests as in the past
anything touching common code has broken builds in unexpected ways leaving
other people to clean the mess up.

We already have ways to limit what builds are run based on the files
changed so if we wanted to skip builds in the cases that only certain
board/arch changes are a touched that is possible with someone willing to
do the work.

You will note if you change only files in Documentation/** only the docs
get built.

I have also asked in the past about cutting down on the amount of configs
we have checked in to be something like

board:nsh -- only nsh and somewhat small
board:jumbo -- nsh, plus as many features as can fit and are interesting in
the platform.

For sim and some other targets it would make sense to have more targets,
but not for every board.

--Brennan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Lee, Lup Yuen]

Maybe we can run the CI Tests once a day, so it's easier to backtrack? FYI
I've run Automated Tests on BL602 NuttX over the past 365 days (except for
the brief Makefile outage last week):

https://github.com/lupyuen/nuttx/tags

Here's how it works:

https://lupyuen.github.io/articles/auto

Lup

On Tue, May 23, 2023 at 3:33 PM Sebastien Lorquet 
wrote:

> Hello,
>
> even if theoretically nice to do, do we really, actually, need to do
> that for the purpose of checking *every* pull request, which are quite
> numerous?
>
> Could that not be done once before a release?
>
> Sebastien
>
> Le 22/05/2023 à 22:31, Maciej Wójcik a écrit :
> > Checking different configurations is an academic problem, I think they
> call
> > it configuration sampling and it is part of variability modelling. There
> > were some papers about sampling of Linux configurations.
> >
> > The simplest approach is to enable all possible, disable all possible,
> but
> > it is not trivial. Each selection multiplies the number of configurations
> > by the number of available options. That has very bad complexity.
> >
> > They use SAT solvers to generate many configurations instead of brute
> > force. The goal is to sample configuration space in a uniform way.
> >
> > Am Mo., 22. Mai 2023 um 21:14 Uhr schrieb Nathan Hartman <
> > hartman.nat...@gmail.com>:
> >
> >> On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet  >
> >> wrote:
> >>
> >>> If the untold reason is to speed up github tests, then run less tests.
> >>> Do we really need to test build on 13 or 20 arm platforms when only one
> >>> config of the other architectures is tested, and the actual value of
> >>> these build test is dubious?
> >>
> >>
> >> This is an interesting point. It reminds me that (at least in the old
> days,
> >> I don't know now) FreeBSD had a build config that basically enabled all
> >> options, even if that's impossible for actually running, for build
> testing.
> >> I don't know if we can do that but maybe we need one ARM config that
> >> enables as many options as possible and then use other archs for other
> >> tests.
> >>
> >> Just a thought
> >>
> >> Nathan
> >>
>

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Sebastien Lorquet]

Hello,

even if theoretically nice to do, do we really, actually, need to do 
that for the purpose of checking *every* pull request, which are quite 
numerous?


Could that not be done once before a release?

Sebastien

Le 22/05/2023 à 22:31, Maciej Wójcik a écrit :

Checking different configurations is an academic problem, I think they call
it configuration sampling and it is part of variability modelling. There
were some papers about sampling of Linux configurations.

The simplest approach is to enable all possible, disable all possible, but
it is not trivial. Each selection multiplies the number of configurations
by the number of available options. That has very bad complexity.

They use SAT solvers to generate many configurations instead of brute
force. The goal is to sample configuration space in a uniform way.

Am Mo., 22. Mai 2023 um 21:14 Uhr schrieb Nathan Hartman <
hartman.nat...@gmail.com>:


On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet 
wrote:


If the untold reason is to speed up github tests, then run less tests.
Do we really need to test build on 13 or 20 arm platforms when only one
config of the other architectures is tested, and the actual value of
these build test is dubious?



This is an interesting point. It reminds me that (at least in the old days,
I don't know now) FreeBSD had a build config that basically enabled all
options, even if that's impossible for actually running, for build testing.
I don't know if we can do that but maybe we need one ARM config that
enables as many options as possible and then use other archs for other
tests.

Just a thought

Nathan

Re: [OT] Learning Makefiles

[Sebastien Lorquet]

Hello Tomek,

Whatever is decided, the mere fact of wanting to make a decision on this 
point will lead to more split.


either from people that want cmake

or from people who dont.

this is an intrinsically bad decision

Sebastien


Le 23/05/2023 à 01:41, Tomek CEDRO a écrit :

I can see that this decision will be quite controversial and it cannot
lead to any more split in the community.

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Xiang Xiao]

Why not start the test infrastructure from sim/qemu? It's more simple to
set up and has unlimited resources. Once the sim/qemu test workflow is
ready, it isn't very hard to duplicate to the real boards.

On Tue, May 23, 2023 at 8:42 AM Alan C. Assis  wrote:

> On 5/22/23, Tomek CEDRO  wrote:
> > This is why I asked not that long ago about
> > Software-Hardware-Support-Compatibility-Matrix.. this would be really
> > big table with hardware boards in columns and features in rows with
> > green marks (or +1) where full support is confirmed, yellow (or 0)
> > meaning work-in-progress, red (or -1) meaning no support or known
> > problems.
> >
> > According to that Compatibility Matrix it would be possible to create
> > proof-based configurations to build, and builds would prove the
> > configurations.
> >
> > To be honest I have no idea how that could be implemented in such a
> > complex project as NuttX with all those possible configurations.. that
> > would really require big CI automation and I am not really familiar
> > with GH CI yet maybe this is possible.. does GH charge $ for this CI
> > operations? :-)
> >
> > When working for ARM at mbed they had this big wall of boards and such
> > tests were performed not only at build stage but also on a real
> > hardware.. each board had DAPLink that allowed flashing and serial
> > port shell that executed some test scripts :-)
> >
>
> Yes, I and Sebastien tried to create a testing farm for NuttX using
> Raspberry Pi:
>
> https://bitbucket.org/acassis/raspi-nuttx-farm/src/master/
>
> but soon we realize it will not scale well, for each board we need a
> Raspi, or a USB HUB with Power Control over on each port (to
> physically turn ON/OFF the board).
>
> In the past using Raspberry Pi Zero was a good idea:
> https://www.raspberrypi.com/news/raspberry-pi-zero/
> The price was U$ 5.00, so we could by 100 that it was not too expensive :-)
>
> Maybe a better alternative should be create some USB/HUB board using
> ESP32-S2 that we could use as bridge to program from a central
> computer/board over WiFi.
>
> BR,
>
> Alan
>

Re: [OT] Learning Makefiles

[Tomek CEDRO]

On Tue, May 23, 2023 at 4:28 AM Xiang Xiao wrote:
> CWIKI mayn't be a good place since it requires that the user has an Apache
> account at least to make any change as far as I know.
> It's better to be tracked by a github issue.

That is more to keep RFC and administrative stuff documented.. anyone
from PMC can update.. I have created a content from out mailing list
discussion.. but anything that works best for everyone is fine.. can
be GH Issues sure thing :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [OT] Learning Makefiles

[Xiang Xiao]

CWIKI mayn't be a good place since it requires that the user has an Apache
account at least to make any change as far as I know.
It's better to be tracked by a github issue.

On Tue, May 23, 2023 at 9:27 AM Nathan Hartman 
wrote:

> On Mon, May 22, 2023 at 8:44 PM Alan C. Assis  wrote:
>
> > On 5/22/23, Tomek CEDRO  wrote:
> > > On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> > >> I think it is better to keep the documentation in a single place:
> > >> https://nuttx.apache.org/docs/latest/contributing/index.html
> > >> We're moving those documentations from confluence to our internal
> > >> repository.
> > >> So, that could be nice if you could send patches to Documentation/
> > >> directory directly.
> > >
> > > Yup, cwiki at this moment is a kind of scratchpad, all documentation
> > > is being transferred to git / documentation.. but we may still use
> > > cwiki to keep project administrative information like notes, rfc,
> > > etc..?
> > >
> >
> > No, I don't think so. Please search in the mailing list about this
> > moving docs discussion.
>
>
>
> Docs should move to repo, yes, BUT if I understand correctly Tomek is
> talking about things like ongoing discussions, debates within the
> community, such as arguments for and against adopting CMake. That is not
> documentation for users of NuttX. That is a place for the community to
> collect all the arguments in a debate so they will be easy to reference in
> one place and easy to see if there are more pros than cons, or more cons
> than pros. That should be able to go in the CWIKI and not docs in the repo,
> IMHO.
>
> Cheers
> Nathan
>

Re: [OT] Learning Makefiles

[Nathan Hartman]

On Mon, May 22, 2023 at 8:44 PM Alan C. Assis  wrote:

> On 5/22/23, Tomek CEDRO  wrote:
> > On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> >> I think it is better to keep the documentation in a single place:
> >> https://nuttx.apache.org/docs/latest/contributing/index.html
> >> We're moving those documentations from confluence to our internal
> >> repository.
> >> So, that could be nice if you could send patches to Documentation/
> >> directory directly.
> >
> > Yup, cwiki at this moment is a kind of scratchpad, all documentation
> > is being transferred to git / documentation.. but we may still use
> > cwiki to keep project administrative information like notes, rfc,
> > etc..?
> >
>
> No, I don't think so. Please search in the mailing list about this
> moving docs discussion.



Docs should move to repo, yes, BUT if I understand correctly Tomek is
talking about things like ongoing discussions, debates within the
community, such as arguments for and against adopting CMake. That is not
documentation for users of NuttX. That is a place for the community to
collect all the arguments in a debate so they will be easy to reference in
one place and easy to see if there are more pros than cons, or more cons
than pros. That should be able to go in the CWIKI and not docs in the repo,
IMHO.

Cheers
Nathan

Re: [OT] Learning Makefiles

[Alan C. Assis]

On 5/22/23, Tomek CEDRO  wrote:
> On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
>> I think it is better to keep the documentation in a single place:
>> https://nuttx.apache.org/docs/latest/contributing/index.html
>> We're moving those documentations from confluence to our internal
>> repository.
>> So, that could be nice if you could send patches to Documentation/
>> directory directly.
>
> Yup, cwiki at this moment is a kind of scratchpad, all documentation
> is being transferred to git / documentation.. but we may still use
> cwiki to keep project administrative information like notes, rfc,
> etc..?
>

No, I don't think so. Please search in the mailing list about this
moving docs discussion.

BR,

Alan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Alan C. Assis]

On 5/22/23, Tomek CEDRO  wrote:
> This is why I asked not that long ago about
> Software-Hardware-Support-Compatibility-Matrix.. this would be really
> big table with hardware boards in columns and features in rows with
> green marks (or +1) where full support is confirmed, yellow (or 0)
> meaning work-in-progress, red (or -1) meaning no support or known
> problems.
>
> According to that Compatibility Matrix it would be possible to create
> proof-based configurations to build, and builds would prove the
> configurations.
>
> To be honest I have no idea how that could be implemented in such a
> complex project as NuttX with all those possible configurations.. that
> would really require big CI automation and I am not really familiar
> with GH CI yet maybe this is possible.. does GH charge $ for this CI
> operations? :-)
>
> When working for ARM at mbed they had this big wall of boards and such
> tests were performed not only at build stage but also on a real
> hardware.. each board had DAPLink that allowed flashing and serial
> port shell that executed some test scripts :-)
>

Yes, I and Sebastien tried to create a testing farm for NuttX using
Raspberry Pi:

https://bitbucket.org/acassis/raspi-nuttx-farm/src/master/

but soon we realize it will not scale well, for each board we need a
Raspi, or a USB HUB with Power Control over on each port (to
physically turn ON/OFF the board).

In the past using Raspberry Pi Zero was a good idea:
https://www.raspberrypi.com/news/raspberry-pi-zero/
The price was U$ 5.00, so we could by 100 that it was not too expensive :-)

Maybe a better alternative should be create some USB/HUB board using
ESP32-S2 that we could use as bridge to program from a central
computer/board over WiFi.

BR,

Alan

Re: [OT] Learning Makefiles

[Tomek CEDRO]

On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> I think it is better to keep the documentation in a single place:
> https://nuttx.apache.org/docs/latest/contributing/index.html
> We're moving those documentations from confluence to our internal repository.
> So, that could be nice if you could send patches to Documentation/
> directory directly.

Yup, cwiki at this moment is a kind of scratchpad, all documentation
is being transferred to git / documentation.. but we may still use
cwiki to keep project administrative information like notes, rfc,
etc..?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [OT] Learning Makefiles

[Alan C. Assis]

On 5/22/23, Tomek CEDRO  wrote:
> On Sat, May 20, 2023 at 2:12 AM Brennan Ashton wrote:
>> On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
>> > I am thinking about this. "If it works don't fix it" comes to my mind.
>> > Current build system is amazingly simple coherent and fast. Building
>> > firmware takes 17 seconds. Why change it?
>> > Such change will flip everything upside down. Adds lots of work and
>> > even more possible problems.
>> > What would be the real benefit?
>> > How would it improve that 17 seconds?
>> > I think the practical presentation and comparison of results (i.e. ide
>> > integration, ci automation) along with numbers (i.e. build time) needs
>> > to take place before making any decisions.
>>
>> I very much disagree. The current build system is much slower with a ton
>> of
>> boilerplate that is difficult to maintain and make cross platform. Are we
>> building an RTOS or reinventing the modern build tools?
>>
>> Infact I have pull requests unmerged because the hacks we have in place
>> break and I have very little interest in tacking on even more hacks when
>> we
>> could just not worry about it with cmake.
>>
>> I would encourage those that thing this complicates things to actually
>> look
>> at the pull requests for cmake and see how much cleaner it is.
>
> Thanks Brennan, this is a solid pro for cmake, we need to create
> detailed list pros and cons, verify in practice, to get better proof
> based RFC analysis.
>
> I can see that this decision will be quite controversial and it cannot
> lead to any more split in the community.
>
> I have created a simple page at CWIKI with an initial list of impacts,
> pros, cons. Please update folks. I have updated Proposals name to
> NuttX RFC Proposals. Big changes like that can be processed that way
> as RFC and documented on cwiki.
>
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+RFC+0004%3A+Add+CMake+build+system
>

I think it is better to keep the documentation in a single place:

https://nuttx.apache.org/docs/latest/contributing/index.html

We're moving those documentations from confluence to our internal repository.

So, that could be nice if you could send patches to Documentation/
directory directly.

BR,

Alan

Re: [OT] Learning Makefiles

[Tomek CEDRO]

On Sat, May 20, 2023 at 2:12 AM Brennan Ashton wrote:
> On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
> > I am thinking about this. "If it works don't fix it" comes to my mind.
> > Current build system is amazingly simple coherent and fast. Building
> > firmware takes 17 seconds. Why change it?
> > Such change will flip everything upside down. Adds lots of work and
> > even more possible problems.
> > What would be the real benefit?
> > How would it improve that 17 seconds?
> > I think the practical presentation and comparison of results (i.e. ide
> > integration, ci automation) along with numbers (i.e. build time) needs
> > to take place before making any decisions.
>
> I very much disagree. The current build system is much slower with a ton of
> boilerplate that is difficult to maintain and make cross platform. Are we
> building an RTOS or reinventing the modern build tools?
>
> Infact I have pull requests unmerged because the hacks we have in place
> break and I have very little interest in tacking on even more hacks when we
> could just not worry about it with cmake.
>
> I would encourage those that thing this complicates things to actually look
> at the pull requests for cmake and see how much cleaner it is.

Thanks Brennan, this is a solid pro for cmake, we need to create
detailed list pros and cons, verify in practice, to get better proof
based RFC analysis.

I can see that this decision will be quite controversial and it cannot
lead to any more split in the community.

I have created a simple page at CWIKI with an initial list of impacts,
pros, cons. Please update folks. I have updated Proposals name to
NuttX RFC Proposals. Big changes like that can be processed that way
as RFC and documented on cwiki.

https://cwiki.apache.org/confluence/display/NUTTX/NuttX+RFC+0004%3A+Add+CMake+build+system

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Tomek CEDRO]

This is why I asked not that long ago about
Software-Hardware-Support-Compatibility-Matrix.. this would be really
big table with hardware boards in columns and features in rows with
green marks (or +1) where full support is confirmed, yellow (or 0)
meaning work-in-progress, red (or -1) meaning no support or known
problems.

According to that Compatibility Matrix it would be possible to create
proof-based configurations to build, and builds would prove the
configurations.

To be honest I have no idea how that could be implemented in such a
complex project as NuttX with all those possible configurations.. that
would really require big CI automation and I am not really familiar
with GH CI yet maybe this is possible.. does GH charge $ for this CI
operations? :-)

When working for ARM at mbed they had this big wall of boards and such
tests were performed not only at build stage but also on a real
hardware.. each board had DAPLink that allowed flashing and serial
port shell that executed some test scripts :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Maciej Wójcik]

Checking different configurations is an academic problem, I think they call
it configuration sampling and it is part of variability modelling. There
were some papers about sampling of Linux configurations.

The simplest approach is to enable all possible, disable all possible, but
it is not trivial. Each selection multiplies the number of configurations
by the number of available options. That has very bad complexity.

They use SAT solvers to generate many configurations instead of brute
force. The goal is to sample configuration space in a uniform way.

Am Mo., 22. Mai 2023 um 21:14 Uhr schrieb Nathan Hartman <
hartman.nat...@gmail.com>:

> On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet 
> wrote:
>
> >
> > If the untold reason is to speed up github tests, then run less tests.
> > Do we really need to test build on 13 or 20 arm platforms when only one
> > config of the other architectures is tested, and the actual value of
> > these build test is dubious?
>
>
>
> This is an interesting point. It reminds me that (at least in the old days,
> I don't know now) FreeBSD had a build config that basically enabled all
> options, even if that's impossible for actually running, for build testing.
> I don't know if we can do that but maybe we need one ARM config that
> enables as many options as possible and then use other archs for other
> tests.
>
> Just a thought
>
> Nathan
>

CI tests (was: Re: [OT] Learning Makefiles)

[Nathan Hartman]

On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet 
wrote:

>
> If the untold reason is to speed up github tests, then run less tests.
> Do we really need to test build on 13 or 20 arm platforms when only one
> config of the other architectures is tested, and the actual value of
> these build test is dubious?



This is an interesting point. It reminds me that (at least in the old days,
I don't know now) FreeBSD had a build config that basically enabled all
options, even if that's impossible for actually running, for build testing.
I don't know if we can do that but maybe we need one ARM config that
enables as many options as possible and then use other archs for other
tests.

Just a thought

Nathan

Re: [OT] Learning Makefiles

[Sebastien Lorquet]

Hello,

Build performance is not an argument. it's already very fast.

Integration with various tools is a case of "I dont like it", it's not a 
good reason for such a fundamental change, it can be resolved with local 
configurations.


I cant find any good reason to change except, maybe, complexity, with 
reserves. Again possibly in the "NIH"or "dont like it" category.


One more con: we add a dependency on yet another external tool.

As we say in french it's a hammer to crush a fly.

When a vote happen, my vote will be NO. I know it's not binding so it's 
not counted, but I dont care. I'm against this change.


If the untold reason is to speed up github tests, then run less tests. 
Do we really need to test build on 13 or 20 arm platforms when only one 
config of the other architectures is tested, and the actual value of 
these build test is dubious?


Sebastien


Le 22/05/2023 à 14:57, Alan C. Assis a écrit :

Hi Sebastien,

There are good cons and pros arguments for moving to CMake.

Just like many here I don' t have preference for one or another, but
we need to analyze what is better for NuttX evolution and make a good
decision.

The main pros of moving to CMake:

1) It is easier to integrate with new projects and IDEs
2) It will speed up the compilation of the building system
3) It will avoid cumbersome integration to make things work (see
Brennan comments)

The main cons of moving to CMake:

1) The current building system already works "fine" ("If it is not
broken, don't fix", comfort zone)
2) It could spend time and energy to maintain two building systems
during the transition period
3) People will need to learn a new too, although CMake seems easy at
first look, it is hard when you want to do something different.

I think I depicted the three more important point, case someone else
thing about some other important point of each side, please bring it
to the table.

BR,

Alan

On 5/22/23, Sebastien Lorquet  wrote:

I very much agree with all of these arguments.

Thats a too large disruption for too little benefits.

I dont want to be forced to use cmake.

Everything we use here to integrate NuttX is based on makefiles.

Why do we have to bring in yet another dependency? No, cmake is not
installed in our build systems.

Sebastien


Le 20/05/2023 à 00:23, Tomek CEDRO a écrit :

I am thinking about this. "If it works don't fix it" comes to my mind.

Current build system is amazingly simple coherent and fast. Building
firmware takes 17 seconds. Why change it?

Such change will flip everything upside down. Adds lots of work and
even more possible problems.

What would be the real benefit?

How would it improve that 17 seconds?

I think the practical presentation and comparison of results (i.e. ide
integration, ci automation) along with numbers (i.e. build time) needs
to take place before making any decisions.

Re: [OT] Learning Makefiles

[Alan C. Assis]

Hi Sebastien,

There are good cons and pros arguments for moving to CMake.

Just like many here I don' t have preference for one or another, but
we need to analyze what is better for NuttX evolution and make a good
decision.

The main pros of moving to CMake:

1) It is easier to integrate with new projects and IDEs
2) It will speed up the compilation of the building system
3) It will avoid cumbersome integration to make things work (see
Brennan comments)

The main cons of moving to CMake:

1) The current building system already works "fine" ("If it is not
broken, don't fix", comfort zone)
2) It could spend time and energy to maintain two building systems
during the transition period
3) People will need to learn a new too, although CMake seems easy at
first look, it is hard when you want to do something different.

I think I depicted the three more important point, case someone else
thing about some other important point of each side, please bring it
to the table.

BR,

Alan

On 5/22/23, Sebastien Lorquet  wrote:
> I very much agree with all of these arguments.
>
> Thats a too large disruption for too little benefits.
>
> I dont want to be forced to use cmake.
>
> Everything we use here to integrate NuttX is based on makefiles.
>
> Why do we have to bring in yet another dependency? No, cmake is not
> installed in our build systems.
>
> Sebastien
>
>
> Le 20/05/2023 à 00:23, Tomek CEDRO a écrit :
>> I am thinking about this. "If it works don't fix it" comes to my mind.
>>
>> Current build system is amazingly simple coherent and fast. Building
>> firmware takes 17 seconds. Why change it?
>>
>> Such change will flip everything upside down. Adds lots of work and
>> even more possible problems.
>>
>> What would be the real benefit?
>>
>> How would it improve that 17 seconds?
>>
>> I think the practical presentation and comparison of results (i.e. ide
>> integration, ci automation) along with numbers (i.e. build time) needs
>> to take place before making any decisions.
>>
>

Re: [OT] Learning Makefiles

[Sebastien Lorquet]

I very much agree with all of these arguments.

Thats a too large disruption for too little benefits.

I dont want to be forced to use cmake.

Everything we use here to integrate NuttX is based on makefiles.

Why do we have to bring in yet another dependency? No, cmake is not 
installed in our build systems.


Sebastien


Le 20/05/2023 à 00:23, Tomek CEDRO a écrit :

I am thinking about this. "If it works don't fix it" comes to my mind.

Current build system is amazingly simple coherent and fast. Building
firmware takes 17 seconds. Why change it?

Such change will flip everything upside down. Adds lots of work and
even more possible problems.

What would be the real benefit?

How would it improve that 17 seconds?

I think the practical presentation and comparison of results (i.e. ide
integration, ci automation) along with numbers (i.e. build time) needs
to take place before making any decisions.

Re: [OT] Learning Makefiles

[Brennan Ashton]

On Fri, May 19, 2023, 3:23 PM Tomek CEDRO  wrote:

> I am thinking about this. "If it works don't fix it" comes to my mind.
>
> Current build system is amazingly simple coherent and fast. Building
> firmware takes 17 seconds. Why change it?
>
> Such change will flip everything upside down. Adds lots of work and
> even more possible problems.
>
> What would be the real benefit?
>
> How would it improve that 17 seconds?
>
> I think the practical presentation and comparison of results (i.e. ide
> integration, ci automation) along with numbers (i.e. build time) needs
> to take place before making any decisions.
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



I very much disagree. The current build system is much slower with a ton of
boilerplate that is difficult to maintain and make cross platform. Are we
building an RTOS or reinventing the modern build tools?

Infact I have pull requests unmerged because the hacks we have in place
break and I have very little interest in tacking on even more hacks when we
could just not worry about it with cmake.

I would encourage those that thing this complicates things to actually look
at the pull requests for cmake and see how much cleaner it is.

--Brennan

>
>

Re: [OT] Learning Makefiles

[Tomek CEDRO]

I am thinking about this. "If it works don't fix it" comes to my mind.

Current build system is amazingly simple coherent and fast. Building
firmware takes 17 seconds. Why change it?

Such change will flip everything upside down. Adds lots of work and
even more possible problems.

What would be the real benefit?

How would it improve that 17 seconds?

I think the practical presentation and comparison of results (i.e. ide
integration, ci automation) along with numbers (i.e. build time) needs
to take place before making any decisions.

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [OT] Learning Makefiles

[Nathan Hartman]

On Fri, May 19, 2023 at 12:53 PM Gregory Nutt  wrote:

> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
> > Alan,
> >
> > Can you summarize? I have not been following this PR. Is make going away?
> >
> > Thanks,
> >
> > -Lwazi
> >
> > On Fri, 19 May 2023 at 11:47, Alan C. Assis  wrote:
> >> Hi Everyone,
> >>
> >> While PR #6718 is waiting to get merged, please take a look:
> >>
> >> https://makefiletutorial.com
> >>
> >> BR,
> >>
> >> Alan
>
> The decision to switch from GNU Make to CMake is highly controversial.
> Many people are wildly in favor and a large number are strong opposed.
> This is a change that must be brought before the PMC for a vote before
> any action is taken.
>
> Special rules apply to code change votes.  We don't often do votes on
> code changes.  But such votes are critical in order to serve the
> community with fairness.



I'm neutral regarding CMake but *if* the project wants to think about a
switch, I do think that we should consider very carefully the pros and
cons, and think about any disruption that might affect users.

If we want to consider supporting both GNU Make and CMake, then we should
consider the benefits against the added maintenance burden and possible
different behaviors that could occur because of inconsistencies between the
two systems. I am usually opposed to spreading our limited resources thin
over redundant systems.

Nevertheless I am neutral and happy for the project to choose whatever is
best, as long as we can reach a useful consensus as a community.

Note that work began on CMake support in PRs such as 3704 and 6718. If the
community is interested in CMake support, we shouldn't throw away that work.

Cheers,
Nathan

Re: [OT] Learning Makefiles

[Tomek CEDRO]

On Fri, May 19, 2023 at 8:10 PM Gregory Nutt wrote:
> > Such a big change needs good description.. risks.. clear list of
> > advantages and disadvantages :-)
>
> And if it comes down to switching from one to the other as you suggest,
> then it needs a vote to understand the will of the whole community, not
> the preference of a few.  The whole community would have to support the
> switch in every product build environment they maintain.
>
> So I would add the we would need a good understanding of the impact to
> product builds as well.

I do not suggest switching.. when it comes to IT I am really
conservative.. and I like NuttX for NOT following fashions blindly :-)

I remember there was a discussion some years back about cmake and it
was no go.. I just want everyone to understand the status, process
and, implications. There was in idea to use Python in the build and it
was no go as well back then, but today I can see Python is involved in
the build process. So it looks more like evolution rather than
revolution..?

I like CMake, lots of projects use it already, even on BSD everything
"just works".. although it has different syntax and is more
restrictive, it seems also well established solution, allows using
different build mechanisms (even Makefiles), and that enables good
integration with other automation / development tools.. I must admit
that.

Another advantage is build being done in a dedicated directory without
touching the source tree. That may enable building variants, even
different applications for different boards on the same source tree.
This may enable more efficient automation.

I am wondering about the initial configuration process, this part will
have to change too, but it will not change dramatically (i.e.
configure myboard:myconfig -> cmake -B myboard_myconfig -S .
BOARD=myboard CONFIG=myconfig, and then the rest will remain the
same)?

If the change gets vote in favor I think that eventually Make will be
replaced with CMake. I do not really like division of the community
into "Make" and "CMake" groups.. this will lead to incoherent
solution, bugs, mess, and interpersonal fights. We should really avoid
that.

Tremendous amount of work seems to be done. I am not really pro or
against. If things work well I do not like changing them. But if the
new feature proves itself with clear advantages then why not.

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [OT] Learning Makefiles

[Gregory Nutt]

On 5/19/2023 12:11 PM, Lwazi Dube wrote:

On Fri, 19 May 2023 at 13:51, Alan C. Assis  wrote:

Lwazi, I think Greg summarized it well.


Yes, and Maciej too. Thanks


But we need to get away from statements of fears and marketing 
statements to understand the clear, real world impacts.

Re: [OT] Learning Makefiles

[Lwazi Dube]

On Fri, 19 May 2023 at 13:51, Alan C. Assis  wrote:
>
> Lwazi, I think Greg summarized it well.
>
Yes, and Maciej too. Thanks

Re: [OT] Learning Makefiles

[Gregory Nutt]

Such a big change needs good description.. risks.. clear list of
advantages and disadvantages :-)


And if it comes down to switching from one to the other as you suggest, 
then it needs a vote to understand the will of the whole community, not 
the preference of a few.  The whole community would have to support the 
switch in every product build environment they maintain.


So I would add the we would need a good understanding of the impact to 
product builds as well.

Re: [OT] Learning Makefiles

[Alan C. Assis]

On 5/19/23, Gregory Nutt  wrote:
> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
>> Alan,
>>
>> Can you summarize? I have not been following this PR. Is make going away?
>>
>> Thanks,
>>
>> -Lwazi
>>
>> On Fri, 19 May 2023 at 11:47, Alan C. Assis  wrote:
>>> Hi Everyone,
>>>
>>> While PR #6718 is waiting to get merged, please take a look:
>>>
>>> https://makefiletutorial.com
>>>
>>> BR,
>>>
>>> Alan
>
> The decision to switch from GNU Make to CMake is highly controversial.
> Many people are wildly in favor and a large number are strong opposed.
> This is a change that must be brought before the PMC for a vote before
> any action is taken.
>
> Special rules apply to code change votes.  We don't often do votes on
> code changes.  But such votes are critical in order to serve the
> community with fairness.
>
>

Lwazi, I think Greg summarized it well.

This CMake is a long date discussion and it already created wounds in
our community (we "lost" a great contributor/developer that proposed
and submitted the initial patches to support CMake).

I don't strong opinion about Makefile or CMake, the current Makefile
works fine, the make advantage of CMake is it will integrated better
with "modern" software that are build using CMake.

Maybe others with better experience with it could give more details
about its advantages and/or disadvantages.

BR,

Alan

Re: [OT] Learning Makefiles

[Maciej Wójcik]

I see the following advantages of having CMake:
- Everything is way more readable then the current Make files.
- Easier on-boarding.
- Less build-related bugs.
- Less boiler-plate code.
- Faster builds.
- Great IDE integration.

Adding CMake as an optional feature seems to be a great solution.

Maintaining two systems for a while requires more work, but it would be a
backward-compatible way to polish the solution.

For trivial problems it is still just adding files to lists, right? For
more complex issues, I am pretty sure that parties attached to Make will
maintain it just fine and people who want CMake will fix it for themselves.

The discussion so far was that:
- Replacing Make breaks existing workflows.
- CMake is less flexible.
- Duplicated maintenance effort.

By just adding CMake no workflows are broken
If the new solution is able to recreate the previous build system, then it
is flexible enough.
I guess that overlapping maintenance effort is the only way to offer
backward compatibility.

I would like to point out that offering CMake is what people expect to have
from a modern project and NuttX is currently not offering it.

Am Fr., 19. Mai 2023 um 19:26 Uhr schrieb Tomek CEDRO :

> On Fri, May 19, 2023 at 7:17 PM Xiang Xiao wrote:
> > The change doesn't replace Makefile with CMake, both can work. So I would
> > suggest the vote is "Enable CMake support".
>
> Isn't the goal of CMake to generate Makefiles?
>
> What is the chance of keeping both makefiles and cmakefiles out of sync?
>
> Wouldn't that double the work?
>
> Wouldn't that imply switch to CMake anyways?
>
> From what I understand CMake can offer faster builds using different
> build methods / systems, it could eliminate GNU Make vs BSD Make
> problem, but also it will change whole build process, changes
> frequently, etc..?
>
> Such a big change needs good description.. risks.. clear list of
> advantages and disadvantages :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: [OT] Learning Makefiles

[Tomek CEDRO]

On Fri, May 19, 2023 at 7:17 PM Xiang Xiao wrote:
> The change doesn't replace Makefile with CMake, both can work. So I would
> suggest the vote is "Enable CMake support".

Isn't the goal of CMake to generate Makefiles?

What is the chance of keeping both makefiles and cmakefiles out of sync?

Wouldn't that double the work?

Wouldn't that imply switch to CMake anyways?

>From what I understand CMake can offer faster builds using different
build methods / systems, it could eliminate GNU Make vs BSD Make
problem, but also it will change whole build process, changes
frequently, etc..?

Such a big change needs good description.. risks.. clear list of
advantages and disadvantages :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [OT] Learning Makefiles

[Xiang Xiao]

The change doesn't replace Makefile with CMake, both can work. So I would
suggest the vote is "Enable CMake support".

On Sat, May 20, 2023 at 12:53 AM Gregory Nutt  wrote:

> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
> > Alan,
> >
> > Can you summarize? I have not been following this PR. Is make going away?
> >
> > Thanks,
> >
> > -Lwazi
> >
> > On Fri, 19 May 2023 at 11:47, Alan C. Assis  wrote:
> >> Hi Everyone,
> >>
> >> While PR #6718 is waiting to get merged, please take a look:
> >>
> >> https://makefiletutorial.com
> >>
> >> BR,
> >>
> >> Alan
>
> The decision to switch from GNU Make to CMake is highly controversial.
> Many people are wildly in favor and a large number are strong opposed.
> This is a change that must be brought before the PMC for a vote before
> any action is taken.
>
> Special rules apply to code change votes.  We don't often do votes on
> code changes.  But such votes are critical in order to serve the
> community with fairness.
>
>
>
>

Re: [OT] Learning Makefiles

[Gregory Nutt]

On 5/19/2023 10:25 AM, Lwazi Dube wrote:

Alan,

Can you summarize? I have not been following this PR. Is make going away?

Thanks,

-Lwazi

On Fri, 19 May 2023 at 11:47, Alan C. Assis  wrote:

Hi Everyone,

While PR #6718 is waiting to get merged, please take a look:

https://makefiletutorial.com

BR,

Alan


The decision to switch from GNU Make to CMake is highly controversial.  
Many people are wildly in favor and a large number are strong opposed.  
This is a change that must be brought before the PMC for a vote before 
any action is taken.


Special rules apply to code change votes.  We don't often do votes on 
code changes.  But such votes are critical in order to serve the 
community with fairness.

Re: [OT] Learning Makefiles

[Lwazi Dube]

Alan,

Can you summarize? I have not been following this PR. Is make going away?

Thanks,

-Lwazi

On Fri, 19 May 2023 at 11:47, Alan C. Assis  wrote:
>
> Hi Everyone,
>
> While PR #6718 is waiting to get merged, please take a look:
>
> https://makefiletutorial.com
>
> BR,
>
> Alan