Re: Undefined reference to longjmp/setjmp

[Xiang Xiao]

Since setjmp and longjmp need be called from userspace, the location is
moved to:
libs/libc/machine/arch
Here is the related issue and PR:
https://github.com/apache/incubator-nuttx/issues/2478
https://github.com/apache/incubator-nuttx/pull/3315


On Thu, Jun 10, 2021 at 2:51 AM David S. Alessio 
wrote:

> Hello, Foti,
>
> I wrote setjmp/longjmp for armv7-m some time ago.  The code should be in
> file:
> arch/arm/src/armv7-m/gnu/up_setjmp.S
>
> If not, it’s attached here.
>
> Cheers,
> -david
>
>
>
>
>
>
>
>
> On Jun 9, 2021, at 11:10 AM, Fotis Panagiotopoulos 
> wrote:
>
> Hi everyone!
>
> I just started adding Lua to my NuttX-based project, but I have some
> problems with it.
> I am getting undefined references to longjmp/setjmp.
>
> I am using an STM32F4 and GCC:
> arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
> 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
>
> As I see, this combination of arch and compiler should work for
> setjmp/longjmp, so I believe that something is misconfigured on my side.
>
> Is there any special Kconfig option that I am not aware of? Do I need any
> special compiler flags?
>
>
>

Re: [Discuss] Migrate the build system to CMake

[Matias N.]

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%5B%5D=.pl%5B%5D=.sh%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.  > 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
> 

Re: [Discuss] Migrate the build system to CMake

[Nathan Hartman]

On Wed, Jun 9, 2021 at 3:07 PM Matias N.  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

Re: [Discuss] Migrate the build system to CMake

[Maciej Wójcik]

Quoting Sebastien:

> It it's not broken, dont fix it.
> - it works for its intended purposes
> - it is pretty complex
> - ALL USERS have become used to it

Sebastien, what tools are you using for development? Make has such poor
support for any tooling.
Some IDE's understand it partially, some not at all. By using Make we are
rejecting all the help
that IDE's offer. NuttX code base is too large to work efficiently without
it. Complex is not
a feature I think. Yes, people are used to it, because they have to. The
same way one can
get used to winter or to walk in uncomfortable shoes.

> No one will understand the build system anymore

I have been looking at the current Make solution for the last few years and
I wouldn't
say I understand or control it either.

Quoting Alin:

> I like the cmake idea but we should also consider that cmake will have
implications on all projects
> that use the NuttX as a base for the SDK or custom projects.

I am still stuck with NuttX 7.31 because of changes in the Make build
system, so I understand
what you are saying. My projects are small and I still don't have resources
to migrate applications.
I cannot even imagine how big of a burden it is, for developers of larger
frameworks, but it shouldn't
block progress. I think CMake will pay off over time.

Quoting Nathan

> Can't a CMake build be an OPTIONAL component for people who want to use
it?

Quoting Matias

> Maintaining two build systems in parallel does not really make sense to
me.

Matias, just a question, does your work so far collide much with the
current Make build system.
I could take your branch and put the previous solution back next to your
changes. It is hard to
convince people to switch until they see that something works well.

Quoting Juha

> There is no problem to solve here but potential for massive breakage and
extra burden
> on companies using NuttX to develop real products.

This is suggesting that everyone who considers CMake a good idea is an
amateur.
Yes, every change is a burden, but when projects don't develop, the look...
well,
like a Make build system.

Quoting Ken

> CMake is horrible. Don't do it. It's hard to use for beginners, and
> hard to use for anyone who isn't just a strong advocate for it.

Yea I don't like it either, I don't like either Make or CMake. I don't
think that anyone likes
them because they are just building systems, they are boring and
unrewarding.
But regarding beginners, I think you are wrong. One opens a project that
uses CMake
in an IDE and it works. Open a project that uses Make and it doesn't. After
spending
a lot of time trying to make it work, it is fine, but it is never perfect.
Everyone who starts
using NuttX needs to go through this. This is an unnecessary steep learning
curve.
We could say that this way, we filter out inexperienced people from
producing noise
in GitHub issues and the Internet in general, but with such an attitude it
would be
not right to call it an open source project anymore.

Quoting Alexander

> We cannot get rid of the make in one commit. If we want CMake, it should
> grow alongside the make.

I agree.

Quoting Fotis

> For me, cmake would be a no.
> The reasons are greatly outlined by Sebastien.
> However, I am not very experienced with it. (I just never liked it...)

If I don't have experience with something I usually don't express my
opinion.
Don't feel that I am attacking you much, I just don't understand how this
is a valid argument. Maybe you are just modest. It is hard to claim to be
experienced with something even after many years of working with it.
Yes, I also don't like CMake :) but I know what it brings, so I am fully in
favor of it.

Quoting Matias

> I find it particularly striking
> that the original e-mail from Xiang was sent two months ago
> requesting others to express any concern and no one responded until
> today.

This is exactly what I thought when I read it. If some people didn't like it
why did they wait for so long? I have a feeling that they didn't believe
that
you would actually manage to do it :)

>From my side, I am trying to not express my opinion if I don't have time to
make
any real contribution. In this case I didn't have time to help, so I kept
silent.

> I will therefore will not continue working on this
> (you can delete the branch)

Come on Matias, no need to behave like this. Also you should wait for the
Earth
to rotate a bit, so all people involved can wake up, think about it,
finally argue
a bit with each other. But I understand your disappointment when reading
this.

I would help you with CMake if I wouldn't be working 14 hours a day trying
to finish delayed projects. Yet I was looking forward to a day when I could
finally use it.

In general I feel like you have a good hunch about good solutions
and I am using a lot of them, either trying to update NuttX to a version
where
you already added something or cherry-picking like crazy. I think that you
are doing a good job with CMake here. You definitely 

Re: [Discuss] Migrate the build system to CMake

[Fotis Panagiotopoulos]

Trying to be fair, (and leaving my personal preference aside).

My machine takes less than 6 seconds to perform a clean build (with ccache).

If a windows machine takes "minutes", then maybe the build system can be
considered broken...

On Wed, Jun 9, 2021, 23:47 TimH  wrote:

> My view on this...bit of a ramble.
>
> I'm new to Nuttx, and have a new/custom board I'm porting it to. Nuttx
> didn't play nicely/easily with either Windows or MAC for me and I
> eventually went to Linux; and have no regrets as life is so much easier
> as result. A full build takes no more than 10seconds compared to minutes
> using WSL and a complete fail on mac.
>
> The current makefile system is a bit clunky, but once you understand it
> - and it really doesn't take long to do so - it works fine and is
> similar to the methodology I've used for years and years and years.
>
> I have no experience of Cmake so my initial reaction is "oh no, just got
> to grips with all of this, why would I want to jump ship to some other
> way of doing it".
>
> If Cmake could have shortened the process of getting a new board ported
> and NuttX running, and made the whole experience better/easier/quicker
> then it would have been a good thing I would think.
>
> But is the point, perhaps, that if you have a project/build that's
> working for a given board there is little incentive to rework your
> enironment just to suit a new methodology?
>
> I think that may point towards concentrating effort on new and/or very
> popular boards, but leave others alone (for now). I suspect - for
> example - that I am one of very few using sama5d2, given the number of
> errors I've found (!), so is it really worth the effort to change that
> arch to use Cmake?
>
> It may be though! But, as I said, I don't know Cmake so it's very very
> difficult to give a meaningful opinion.
>
> My final thought is "if it ain't broke, don't fix it". Is the current
> system actually broken?
>
>
>
>

Re: Undefined reference to longjmp/setjmp

[Gregory Nutt]

Lua has been ported to NuttX several times.   If you Google for 
"lua+NuttX" you find lots of hits, many from 
https://nuttx.yahoogroups.narkive.com.


This is from 2018:  https://github.com/tokoro10g/lua-nuttx

We really ought to talk to the Lua team and see if we can upstream the 
changes.  Unsupported ports in NuttX don't have good shelf life.


On 6/9/2021 1:08 PM, David S. Alessio wrote:

Also, if you need/want help with getting Lua to run on NuttX, let me know.  I 
had Lua 5.1.4 on NuttX (5 maybe it was) a long time ago.  I believe I submitted 
a patch to add it, but I can’t find it now.  The addition of Lua to NuttX was 
in the form of a subdirectory in apps containing only a Makefile and a few 
patches.  The Makefile would fetched the Lua tarball, applied the patches, and 
built it.  We can recreate this if interested…

Cheers,
-david


On Jun 9, 2021, at 11:51 AM, David S. Alessio  wrote:

Hello, Foti,

I wrote setjmp/longjmp for armv7-m some time ago.  The code should be in file:
arch/arm/src/armv7-m/gnu/up_setjmp.S

If not, it’s attached here.

Cheers,
-david










On Jun 9, 2021, at 11:10 AM, Fotis Panagiotopoulos mailto:f.j.pa...@gmail.com>> wrote:

Hi everyone!

I just started adding Lua to my NuttX-based project, but I have some
problems with it.
I am getting undefined references to longjmp/setjmp.

I am using an STM32F4 and GCC:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

As I see, this combination of arch and compiler should work for
setjmp/longjmp, so I believe that something is misconfigured on my side.

Is there any special Kconfig option that I am not aware of? Do I need any
special compiler flags?

Re: [Discuss] Migrate the build system to CMake

[TimH]

My view on this...bit of a ramble.

I'm new to Nuttx, and have a new/custom board I'm porting it to. Nuttx 
didn't play nicely/easily with either Windows or MAC for me and I 
eventually went to Linux; and have no regrets as life is so much easier 
as result. A full build takes no more than 10seconds compared to minutes 
using WSL and a complete fail on mac.


The current makefile system is a bit clunky, but once you understand it 
- and it really doesn't take long to do so - it works fine and is 
similar to the methodology I've used for years and years and years.


I have no experience of Cmake so my initial reaction is "oh no, just got 
to grips with all of this, why would I want to jump ship to some other 
way of doing it".


If Cmake could have shortened the process of getting a new board ported 
and NuttX running, and made the whole experience better/easier/quicker 
then it would have been a good thing I would think.


But is the point, perhaps, that if you have a project/build that's 
working for a given board there is little incentive to rework your 
enironment just to suit a new methodology?


I think that may point towards concentrating effort on new and/or very 
popular boards, but leave others alone (for now). I suspect - for 
example - that I am one of very few using sama5d2, given the number of 
errors I've found (!), so is it really worth the effort to change that 
arch to use Cmake?


It may be though! But, as I said, I don't know Cmake so it's very very 
difficult to give a meaningful opinion.


My final thought is "if it ain't broke, don't fix it". Is the current 
system actually broken?

Re: [Discuss] Migrate the build system to CMake

[Fotis Panagiotopoulos]

> but
to me the community response is now quite clear

Is it?
Six people on GitHub (+ some here?) provided positive feedback.
While only one "hates it", and three more dislike it (mostly due to the
huge undertaking and risk  such a change requires).

As said, I am not experienced in cmake, to properly judge the decision.
>From what I have seen here, I just do not consider the advantages as
important enough.

Personally, my "no" is not a hard one.

On Wed, Jun 9, 2021, 23:09 David S. Alessio 
wrote:

>
>
> > On Jun 9, 2021, at 12:20 PM, Brennan Ashton 
> wrote:
> >
> > On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos  >
> > wrote:
> >
> >> For me, cmake would be a no.
> >> The reasons are greatly outlined by Sebastien.
> >>
> >> However, I am not very experienced with it. (I just never liked it...)
> >> Are there any hard advantages that would justify such a migration?
> >>
> >> Are there things that can only be done in cmake, or that are so much
> easier
> >> that it is worth it?
> >> Does it have any special features that we need or definitely want?
> >>
> >
> > So for me here is the short list:
> >
> > The builds a much much faster especially for incremental builds. This is
> > even more true for non Linux environments. This is a big deal for testing
> > as well as for the individual developer.
> >
> > We continue to have to handle issues around OS specific things for paths
> > and scripting tools. For some of this we currently have to carry custom
> > tools to help and those tools are not know outside of the project.
> >
> > Some of our custom tools like mkdeps fall short especially when trying to
> > integrate third party libraries.  We can continue to invest in our tools
> > here or use things that already exist and are well tested.  This has
> been a
> > huge pain getting things like LTP integrated to improve our testing.
> >
> > IDE support. While you can certainly use and IDE with NuttX at it exists
> > today, it is not aware of the build system in any reasonable way which
> does
> > make integration harder.
> >
> > Management of build settings and overrides. These are possible today but
> > much harder to keep consistent across all the different builds as we
> > continue to see.
> >
> >
> > That all said if people are not onboard it's not worth half doing. I have
> > been supportive, but I do not want to push this on people.
>
> Isn’t it possible to try CMake before completely moving over to it?  This
> way people new to CMake can give it a try, play with it, and become
> familiar with it before rejecting it.  I think both make system can
> coexist, but if not, then offer CMake as a top-level patch, i.e.
> Switch-to-CMake.patch that’s applied to the NuttX top level tree.  I’m not
> suggesting this as a permanent mechanism, just during the
> test-before-transition stage.
>
> Assumption: I don’t believe anyone is suggesting changing or eliminating
> KConfig.  Am I right?
>
> As I see it, CMake would adopt and eliminate a number of pernicious
> problems with the existing gmake build system.  Here are a few:
> The “C” is for Cross-platform, it’s designed to manage host OS and target
> differences
> Windoze filename conventions and variations: Windoze native, Cygwin, etc.
> The use of gmake’s functions, especially “foreach” makes it difficult
> [impossible?] to properly and completely capture dependancies in a way that
> works for parallel builds.  In any case, we haven’t yet succeeded in
> getting parallel builds to work correctly (they sometimes work).
> It supports multiple generators like Xcode, Eclipse, Visual Studio, etc.
>
> For many people new to CMake, CMake is different, and for that reason
> alone it’s bad.  The first few times I had to use it, I hated it.  While I
> can’t say I love it [yet?], I have come to appreciate it.  I believe that
> once it’s implemented, people will realize its value in removing the
> multi-platform headaches and fewer build system breakages.
>
> Just my $0.025.
>
>
>
>
>
>

Re: Undefined reference to longjmp/setjmp

[Gregory Nutt]

There is also a configuration option that must be set to use the setjmp 
in NuttX.  It is in the top-level Kconfig as I recall.


You don't get a compilation error so you are probably including the 
toolchain's setjmp.h.  So most likely you have -nostdlib or something 
like that on the command line so that you do not bring in the 
toolchain's C library version of setjmp/longjmp.


On 6/9/2021 12:51 PM, David S. Alessio wrote:

Hello, Foti,

I wrote setjmp/longjmp for armv7-m some time ago.  The code should be 
in file:

arch/arm/src/armv7-m/gnu/up_setjmp.S

If not, it’s attached here.

Cheers,
-david









On Jun 9, 2021, at 11:10 AM, Fotis Panagiotopoulos 
mailto:f.j.pa...@gmail.com>> wrote:


Hi everyone!

I just started adding Lua to my NuttX-based project, but I have some
problems with it.
I am getting undefined references to longjmp/setjmp.

I am using an STM32F4 and GCC:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

As I see, this combination of arch and compiler should work for
setjmp/longjmp, so I believe that something is misconfigured on my side.

Is there any special Kconfig option that I am not aware of? Do I need any
special compiler flags?

Re: [Discuss] Migrate the build system to CMake

[David S. Alessio]

> On Jun 9, 2021, at 12:20 PM, Brennan Ashton  wrote:
> 
> On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos 
> wrote:
> 
>> For me, cmake would be a no.
>> The reasons are greatly outlined by Sebastien.
>> 
>> However, I am not very experienced with it. (I just never liked it...)
>> Are there any hard advantages that would justify such a migration?
>> 
>> Are there things that can only be done in cmake, or that are so much easier
>> that it is worth it?
>> Does it have any special features that we need or definitely want?
>> 
> 
> So for me here is the short list:
> 
> The builds a much much faster especially for incremental builds. This is
> even more true for non Linux environments. This is a big deal for testing
> as well as for the individual developer.
> 
> We continue to have to handle issues around OS specific things for paths
> and scripting tools. For some of this we currently have to carry custom
> tools to help and those tools are not know outside of the project.
> 
> Some of our custom tools like mkdeps fall short especially when trying to
> integrate third party libraries.  We can continue to invest in our tools
> here or use things that already exist and are well tested.  This has been a
> huge pain getting things like LTP integrated to improve our testing.
> 
> IDE support. While you can certainly use and IDE with NuttX at it exists
> today, it is not aware of the build system in any reasonable way which does
> make integration harder.
> 
> Management of build settings and overrides. These are possible today but
> much harder to keep consistent across all the different builds as we
> continue to see.
> 
> 
> That all said if people are not onboard it's not worth half doing. I have
> been supportive, but I do not want to push this on people.

Isn’t it possible to try CMake before completely moving over to it?  This way 
people new to CMake can give it a try, play with it, and become familiar with 
it before rejecting it.  I think both make system can coexist, but if not, then 
offer CMake as a top-level patch, i.e. Switch-to-CMake.patch that’s applied to 
the NuttX top level tree.  I’m not suggesting this as a permanent mechanism, 
just during the test-before-transition stage.

Assumption: I don’t believe anyone is suggesting changing or eliminating 
KConfig.  Am I right?

As I see it, CMake would adopt and eliminate a number of pernicious problems 
with the existing gmake build system.  Here are a few:
The “C” is for Cross-platform, it’s designed to manage host OS and target 
differences
Windoze filename conventions and variations: Windoze native, Cygwin, etc.
The use of gmake’s functions, especially “foreach” makes it difficult 
[impossible?] to properly and completely capture dependancies in a way that 
works for parallel builds.  In any case, we haven’t yet succeeded in getting 
parallel builds to work correctly (they sometimes work).
It supports multiple generators like Xcode, Eclipse, Visual Studio, etc.

For many people new to CMake, CMake is different, and for that reason alone 
it’s bad.  The first few times I had to use it, I hated it.  While I can’t say 
I love it [yet?], I have come to appreciate it.  I believe that once it’s 
implemented, people will realize its value in removing the multi-platform 
headaches and fewer build system breakages.

Just my $0.025.

Re: [Discuss] Migrate the build system to CMake

[Alan Carvalho de Assis]

Hi Brennan and Matias,

I think it is worth the effort to get the remaining boards converted
to cmake, but I think we need to find an easy way to keep Makefile and
CMake in sync. Otherwise people will have double work adding support
for two building systems.

I don't know if it is easy to create a script to parse the boards'
makefile and convert it to CMakefile.txt, but it could help to keep it
in sync.

Maybe people don't realize the issues with current building system,
because it works fine on Linux. But for other OS it is slow and have
other maintenance issues.

I think it is important to support CMake, but we need a soft
experience/transition.

BR,

Alan

On 6/9/21, Brennan Ashton  wrote:
> On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos 
> wrote:
>
>> For me, cmake would be a no.
>> The reasons are greatly outlined by Sebastien.
>>
>> However, I am not very experienced with it. (I just never liked it...)
>> Are there any hard advantages that would justify such a migration?
>>
>> Are there things that can only be done in cmake, or that are so much
>> easier
>> that it is worth it?
>> Does it have any special features that we need or definitely want?
>>
>
> So for me here is the short list:
>
> The builds a much much faster especially for incremental builds. This is
> even more true for non Linux environments. This is a big deal for testing
> as well as for the individual developer.
>
> We continue to have to handle issues around OS specific things for paths
> and scripting tools. For some of this we currently have to carry custom
> tools to help and those tools are not know outside of the project.
>
> Some of our custom tools like mkdeps fall short especially when trying to
> integrate third party libraries.  We can continue to invest in our tools
> here or use things that already exist and are well tested.  This has been a
> huge pain getting things like LTP integrated to improve our testing.
>
> IDE support. While you can certainly use and IDE with NuttX at it exists
> today, it is not aware of the build system in any reasonable way which does
> make integration harder.
>
> Management of build settings and overrides. These are possible today but
> much harder to keep consistent across all the different builds as we
> continue to see.
>
>
> That all said if people are not onboard it's not worth half doing. I have
> been supportive, but I do not want to push this on people.
>
> --Brennan
>

Re: [Discuss] Migrate the build system to CMake

[Brennan Ashton]

On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos 
wrote:

> For me, cmake would be a no.
> The reasons are greatly outlined by Sebastien.
>
> However, I am not very experienced with it. (I just never liked it...)
> Are there any hard advantages that would justify such a migration?
>
> Are there things that can only be done in cmake, or that are so much easier
> that it is worth it?
> Does it have any special features that we need or definitely want?
>

So for me here is the short list:

The builds a much much faster especially for incremental builds. This is
even more true for non Linux environments. This is a big deal for testing
as well as for the individual developer.

We continue to have to handle issues around OS specific things for paths
and scripting tools. For some of this we currently have to carry custom
tools to help and those tools are not know outside of the project.

Some of our custom tools like mkdeps fall short especially when trying to
integrate third party libraries.  We can continue to invest in our tools
here or use things that already exist and are well tested.  This has been a
huge pain getting things like LTP integrated to improve our testing.

IDE support. While you can certainly use and IDE with NuttX at it exists
today, it is not aware of the build system in any reasonable way which does
make integration harder.

Management of build settings and overrides. These are possible today but
much harder to keep consistent across all the different builds as we
continue to see.


That all said if people are not onboard it's not worth half doing. I have
been supportive, but I do not want to push this on people.

--Brennan

Re: Undefined reference to longjmp/setjmp

[David S. Alessio]

Also, if you need/want help with getting Lua to run on NuttX, let me know.  I 
had Lua 5.1.4 on NuttX (5 maybe it was) a long time ago.  I believe I submitted 
a patch to add it, but I can’t find it now.  The addition of Lua to NuttX was 
in the form of a subdirectory in apps containing only a Makefile and a few 
patches.  The Makefile would fetched the Lua tarball, applied the patches, and 
built it.  We can recreate this if interested…

Cheers,
-david

> On Jun 9, 2021, at 11:51 AM, David S. Alessio  
> wrote:
> 
> Hello, Foti,
> 
> I wrote setjmp/longjmp for armv7-m some time ago.  The code should be in file:
>   arch/arm/src/armv7-m/gnu/up_setjmp.S
> 
> If not, it’s attached here.
> 
> Cheers,
> -david
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Jun 9, 2021, at 11:10 AM, Fotis Panagiotopoulos > > wrote:
>> 
>> Hi everyone!
>> 
>> I just started adding Lua to my NuttX-based project, but I have some
>> problems with it.
>> I am getting undefined references to longjmp/setjmp.
>> 
>> I am using an STM32F4 and GCC:
>> arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
>> 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
>> 
>> As I see, this combination of arch and compiler should work for
>> setjmp/longjmp, so I believe that something is misconfigured on my side.
>> 
>> Is there any special Kconfig option that I am not aware of? Do I need any
>> special compiler flags?
> 

Re: [Discuss] Migrate the build system to CMake

[Matias N.]

As I mentioned before, the linked issue already explains the rationale
behind the proposal. I'm not looking for doing any more convincing as
I rather leave others to express their position.

On a more general note, after today's e-mail numerous responses to the
thread opposing to the change were given. I find it particularly striking
that the original e-mail from Xiang was sent two months ago
requesting others to express any concern and no one responded until
today. 

Given this lack of negative responses and due to positive feedback on GitHub 
from
six users I decided it was worthwhile to build a POC of the change
even before an "official" decision was made, mostly because I was looking
forward to demonstrate that it was feasible and its benefits
(in particular, around half build time for sim). This way there would be
something concrete to discuss about instead of just a proposal and intentions.
So that is the risk I took on my behalf and I'm aware of it.

However, during all this time while I actively communicated my progress and 
kept the migration status checklist up to date, and even followed up Xiang's 
email.
For some reason most of the community chose to remain silent and not expressing
their concerns or dislike. I think that this is a really bad approach 
as it undervalues the effort and time that was put into this.

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).

Best,
Matias

On Wed, Jun 9, 2021, at 15:03, Fotis Panagiotopoulos wrote:
> For me, cmake would be a no.
> The reasons are greatly outlined by Sebastien.
> 
> However, I am not very experienced with it. (I just never liked it...)
> Are there any hard advantages that would justify such a migration?
> 
> Are there things that can only be done in cmake, or that are so much easier
> that it is worth it?
> Does it have any special features that we need or definitely want?
> 
> If it takes X amount of time to migrate, will we gain more than X time of
> reduced maintenance? And when?
> Or will it make working with the project so much more enjoyable, for enough
> people, that at least pays off this way?
> 
> Στις Τετ, 9 Ιουν 2021 στις 5:43 μ.μ., ο/η Alexander Vasiliev <
> alexvasil...@gmail.com > έγραψε:
> 
> > >
> > > Maintaining two build systems in parallel does not really make sense to
> > > me. There should be only one and used and maintained by the community.
> > >
> >
> > We cannot get rid of the make in one commit. If we want CMake, it should
> > grow alongside the make.
> >
> >
> > ср, 9 июн. 2021 г. в 14:32, Ken Pettit  > >:
> >
> > > My opinion:
> > >
> > > CMake is horrible.  Don't do it.  It's hard to use for beginners, and
> > > hard to use for anyone who isn't just a strong advocate for it.
> > >
> > > Just my opionion.
> > > Ken
> > >
> > >
> > > On 6/9/21 6:46 AM, Gregory Nutt wrote:
> > > > I think that there a lot of people like myself who are opposed to the
> > > > CMake change but are remain silent to let the community make the
> > > > decision.  I suspect that the advocates of CMake are having a larger
> > > > voice in the decision.
> > > >
> > > > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
> > > >> Hello,
> > > >>
> > > >> I believe in a stong principle, applied successfully numerous time in
> > > >> my embedded development company:
> > > >>
> > > >>
> > > >> It it's not broken, dont fix it.
> > > >>
> > > >>
> > > >> That applies precisely to this change.
> > > >>
> > > >> The build system we have have the following characteristics
> > > >>
> > > >> -it works for its intended purposes
> > > >>
> > > >> -it is pretty complex
> > > >>
> > > >> -ALL USERS have become used to it
> > > >>
> > > >>
> > > >> Changing it
> > > >>
> > > >> - will bring a lot of new bugs
> > > >>
> > > >> - along with the annoying feeling that these bugs were not necessary
> > > >> in the first place
> > > >>
> > > >> - No one will understand the build system anymore
> > > >>
> > > >> - since makefiles are now generated, we rely on yet another external
> > > >> tool with bugs in itself, and its idiosyncrasies and workarounds.
> > > >>
> > > >>
> > > >> Moreover:
> > > >>
> > > >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
> > > >> the nuttx documentation will become fully obsolete overnight.
> > > >>
> > > >>
> > > >> Gratuitous changes are a hell, they destroy efficiency.
> > > >>
> > > >> They tend to appear more frequently in open source projects, because
> > > >> anyone can bring it change without a single damn given to customer
> > > >> since the code has no warranty of fitness of etc etc open source
> > > >> legalese.
> > > >>
> > > >>
> > > >> If it was me, 

Re: Undefined reference to longjmp/setjmp

[David S. Alessio]

Hello, Foti,I wrote setjmp/longjmp for armv7-m some time ago.  The code should be in file:	arch/arm/src/armv7-m/gnu/up_setjmp.SIf not, it’s attached here.Cheers,-david

up_setjmp.S.gz
Description: GNU Zip compressed data
On Jun 9, 2021, at 11:10 AM, Fotis Panagiotopoulos  wrote:Hi everyone!I just started adding Lua to my NuttX-based project, but I have someproblems with it.I am getting undefined references to longjmp/setjmp.I am using an STM32F4 and GCC:arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major)9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]As I see, this combination of arch and compiler should work forsetjmp/longjmp, so I believe that something is misconfigured on my side.Is there any special Kconfig option that I am not aware of? Do I need anyspecial compiler flags?

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Miguel Wisintainer]

Hi Matias,

No, it´s referent to an app example, if you some example to access the NIMBLE 
on Nuttx



Enviado do Email para Windows 10

Undefined reference to longjmp/setjmp

[Fotis Panagiotopoulos]

Hi everyone!

I just started adding Lua to my NuttX-based project, but I have some
problems with it.
I am getting undefined references to longjmp/setjmp.

I am using an STM32F4 and GCC:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

As I see, this combination of arch and compiler should work for
setjmp/longjmp, so I believe that something is misconfigured on my side.

Is there any special Kconfig option that I am not aware of? Do I need any
special compiler flags?

Re: [Discuss] Migrate the build system to CMake

[Fotis Panagiotopoulos]

For me, cmake would be a no.
The reasons are greatly outlined by Sebastien.

However, I am not very experienced with it. (I just never liked it...)
Are there any hard advantages that would justify such a migration?

Are there things that can only be done in cmake, or that are so much easier
that it is worth it?
Does it have any special features that we need or definitely want?

If it takes X amount of time to migrate, will we gain more than X time of
reduced maintenance? And when?
Or will it make working with the project so much more enjoyable, for enough
people, that at least pays off this way?

Στις Τετ, 9 Ιουν 2021 στις 5:43 μ.μ., ο/η Alexander Vasiliev <
alexvasil...@gmail.com> έγραψε:

> >
> > Maintaining two build systems in parallel does not really make sense to
> > me. There should be only one and used and maintained by the community.
> >
>
> We cannot get rid of the make in one commit. If we want CMake, it should
> grow alongside the make.
>
>
> ср, 9 июн. 2021 г. в 14:32, Ken Pettit :
>
> > My opinion:
> >
> > CMake is horrible.  Don't do it.  It's hard to use for beginners, and
> > hard to use for anyone who isn't just a strong advocate for it.
> >
> > Just my opionion.
> > Ken
> >
> >
> > On 6/9/21 6:46 AM, Gregory Nutt wrote:
> > > I think that there a lot of people like myself who are opposed to the
> > > CMake change but are remain silent to let the community make the
> > > decision.  I suspect that the advocates of CMake are having a larger
> > > voice in the decision.
> > >
> > > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
> > >> Hello,
> > >>
> > >> I believe in a stong principle, applied successfully numerous time in
> > >> my embedded development company:
> > >>
> > >>
> > >> It it's not broken, dont fix it.
> > >>
> > >>
> > >> That applies precisely to this change.
> > >>
> > >> The build system we have have the following characteristics
> > >>
> > >> -it works for its intended purposes
> > >>
> > >> -it is pretty complex
> > >>
> > >> -ALL USERS have become used to it
> > >>
> > >>
> > >> Changing it
> > >>
> > >> - will bring a lot of new bugs
> > >>
> > >> - along with the annoying feeling that these bugs were not necessary
> > >> in the first place
> > >>
> > >> - No one will understand the build system anymore
> > >>
> > >> - since makefiles are now generated, we rely on yet another external
> > >> tool with bugs in itself, and its idiosyncrasies and workarounds.
> > >>
> > >>
> > >> Moreover:
> > >>
> > >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
> > >> the nuttx documentation will become fully obsolete overnight.
> > >>
> > >>
> > >> Gratuitous changes are a hell, they destroy efficiency.
> > >>
> > >> They tend to appear more frequently in open source projects, because
> > >> anyone can bring it change without a single damn given to customer
> > >> since the code has no warranty of fitness of etc etc open source
> > >> legalese.
> > >>
> > >>
> > >> If it was me, I would not do this change. If I had to take a decision
> > >> about something similar in my company, it would be a strong no.
> > >>
> > >>
> > >> Sebastien
> > >>
> > >>
> > >> Le 09/06/2021 à 14:57, Matias N. a écrit :
> > >>> Hi everyone,
> > >>>
> > >>> this thread has received little engagement from the community
> > >>> in general, for a change with such impact on daily use of NuttX
> > >>> for everyone.
> > >>>
> > >>> While there was positive feedback on GH and a few people have
> > >>> expressed more interest, not much has really happened. Meanwhile,
> > >>> the backlog of changes that would need to be backported continues
> > >>> to increase.
> > >>>
> > >>> At the same time, I see many PRs addressing subtle issues with
> > >>> current build system, which are mostly already solved with the
> > >>> migration
> > >>> to CMake. So there's continued effort in maintaining the current
> system
> > >>> which could be in part dedicated to the migration to a better system.
> > >>>
> > >>> I have offered technical guidance on testing and extending to other
> > >>> platforms and also to add base support for other arch's so that the
> > >>> focus
> > >>> can be put mostly at the board level and on test and validation on
> > >>> different
> > >>> platforms and target hardware. However, after having worked on this
> > >>> for more than a month I feel this is not really picking up the
> > >>> interest it
> > >>> requires for proper adoption by the community.
> > >>>
> > >>> Maybe the proper approach would be to call on a vote (*)
> > >>> for this feature to have explicit support from the community and
> > >>> ensure involvement from others than me to move forward.
> > >>> Otherwise, or if the vote does not pass, I will not be pushing
> > >>> forward with this.
> > >>>
> > >>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally
> > >>> call on
> > >>> a vote and what the exact procedure is, but maybe other PPMC member
> > >>> can do so.
> > >>>
> > >>> Best,
> > >>> Matias
> > 

Re: [Discuss] Migrate the build system to CMake

[Alexander Vasiliev]

>
> Maintaining two build systems in parallel does not really make sense to
> me. There should be only one and used and maintained by the community.
>

We cannot get rid of the make in one commit. If we want CMake, it should
grow alongside the make.


ср, 9 июн. 2021 г. в 14:32, Ken Pettit :

> My opinion:
>
> CMake is horrible.  Don't do it.  It's hard to use for beginners, and
> hard to use for anyone who isn't just a strong advocate for it.
>
> Just my opionion.
> Ken
>
>
> On 6/9/21 6:46 AM, Gregory Nutt wrote:
> > I think that there a lot of people like myself who are opposed to the
> > CMake change but are remain silent to let the community make the
> > decision.  I suspect that the advocates of CMake are having a larger
> > voice in the decision.
> >
> > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
> >> Hello,
> >>
> >> I believe in a stong principle, applied successfully numerous time in
> >> my embedded development company:
> >>
> >>
> >> It it's not broken, dont fix it.
> >>
> >>
> >> That applies precisely to this change.
> >>
> >> The build system we have have the following characteristics
> >>
> >> -it works for its intended purposes
> >>
> >> -it is pretty complex
> >>
> >> -ALL USERS have become used to it
> >>
> >>
> >> Changing it
> >>
> >> - will bring a lot of new bugs
> >>
> >> - along with the annoying feeling that these bugs were not necessary
> >> in the first place
> >>
> >> - No one will understand the build system anymore
> >>
> >> - since makefiles are now generated, we rely on yet another external
> >> tool with bugs in itself, and its idiosyncrasies and workarounds.
> >>
> >>
> >> Moreover:
> >>
> >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
> >> the nuttx documentation will become fully obsolete overnight.
> >>
> >>
> >> Gratuitous changes are a hell, they destroy efficiency.
> >>
> >> They tend to appear more frequently in open source projects, because
> >> anyone can bring it change without a single damn given to customer
> >> since the code has no warranty of fitness of etc etc open source
> >> legalese.
> >>
> >>
> >> If it was me, I would not do this change. If I had to take a decision
> >> about something similar in my company, it would be a strong no.
> >>
> >>
> >> Sebastien
> >>
> >>
> >> Le 09/06/2021 à 14:57, Matias N. a écrit :
> >>> Hi everyone,
> >>>
> >>> this thread has received little engagement from the community
> >>> in general, for a change with such impact on daily use of NuttX
> >>> for everyone.
> >>>
> >>> While there was positive feedback on GH and a few people have
> >>> expressed more interest, not much has really happened. Meanwhile,
> >>> the backlog of changes that would need to be backported continues
> >>> to increase.
> >>>
> >>> At the same time, I see many PRs addressing subtle issues with
> >>> current build system, which are mostly already solved with the
> >>> migration
> >>> to CMake. So there's continued effort in maintaining the current system
> >>> which could be in part dedicated to the migration to a better system.
> >>>
> >>> I have offered technical guidance on testing and extending to other
> >>> platforms and also to add base support for other arch's so that the
> >>> focus
> >>> can be put mostly at the board level and on test and validation on
> >>> different
> >>> platforms and target hardware. However, after having worked on this
> >>> for more than a month I feel this is not really picking up the
> >>> interest it
> >>> requires for proper adoption by the community.
> >>>
> >>> Maybe the proper approach would be to call on a vote (*)
> >>> for this feature to have explicit support from the community and
> >>> ensure involvement from others than me to move forward.
> >>> Otherwise, or if the vote does not pass, I will not be pushing
> >>> forward with this.
> >>>
> >>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally
> >>> call on
> >>> a vote and what the exact procedure is, but maybe other PPMC member
> >>> can do so.
> >>>
> >>> Best,
> >>> Matias
> >>>
> >>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
>  I am interested and I'll try to help with boards I can test. It
>  will take a
>  few days to get around to it because this has been a busy month,
>  but I'm
>  catching up.
> 
>  Cheers
>  Nathan
> 
>  On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis
>  mailto:acassis%40gmail.com>>
>  wrote:
> 
> > I think we can divide the effort to port all the boards to the new
> > CMake.
> >
> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> >
> > Let see if we get more people involved in this effort.
> >
> > BR,
> >
> > Alan
> >
> > On 6/1/21, Matias N. mailto:matias%40imap.cc>>
> > wrote:
> >> Hi,
> >> just wanted to add that until this is ready, the gap between
> >> master and
> > the
> >> branch
> >> widens with every merged PR and 

Re: [Discuss] Migrate the build system to CMake

[Ken Pettit]

My opinion:

CMake is horrible.  Don't do it.  It's hard to use for beginners, and 
hard to use for anyone who isn't just a strong advocate for it.


Just my opionion.
Ken


On 6/9/21 6:46 AM, Gregory Nutt wrote:
I think that there a lot of people like myself who are opposed to the 
CMake change but are remain silent to let the community make the 
decision.  I suspect that the advocates of CMake are having a larger 
voice in the decision.


On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:

Hello,

I believe in a stong principle, applied successfully numerous time in 
my embedded development company:



It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary 
in the first place


- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external 
tool with bugs in itself, and its idiosyncrasies and workarounds.



Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of 
the nuttx documentation will become fully obsolete overnight.



Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because 
anyone can bring it change without a single damn given to customer 
since the code has no warranty of fitness of etc etc open source 
legalese.



If it was me, I would not do this change. If I had to take a decision 
about something similar in my company, it would be a strong no.



Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the 
migration

to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the 
focus
can be put mostly at the board level and on test and validation on 
different

platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the 
interest it

requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing 
forward with this.


(*) As a commiter (non-PPMC member), I'm not sure if I can formally 
call on

a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
I am interested and I'll try to help with boards I can test. It 
will take a
few days to get around to it because this has been a busy month, 
but I'm

catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis 
mailto:acassis%40gmail.com>>

wrote:

I think we can divide the effort to port all the boards to the new 
CMake.


I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N. mailto:matias%40imap.cc>> 
wrote:

Hi,
just wanted to add that until this is ready, the gap between 
master and

the

branch
widens with every merged PR and this increases the backporting 
effort.
I'm willing to do most of the remaining work but as I mentioned I 
cannot

possibly test everything so
help is needed.
I'd really like your feedback on this before I continue and 
ensure the

effort will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:

Hi,
for anyone not following the relevant PR, please have a look at the
current state here:

https://github.com/apache/incubator-nuttx/pull/3704

This is now at a point where it can be tested by others. It 
would be

very

good to get some
help testing what I got so far (sim and stm32f4discovery, both 
on Linux

and mac), by running
examples and test. There are some brief instructions at the end 
of the

PR

description for building.

Other than that, I can continue porting other arch's and boards 
with the

help of CI but it would be
best if others with more boards could help testing (and ideally 
with

some

PRs, as the hard part
is mostly done) those as well.

Also, note that this 

Re: [Discuss] Migrate the build system to CMake

[Juha Niskanen (Haltian)]

Hello,

I agree with Sebastien. There is no problem to solve here but potential for 
massive breakage and extra burden on companies using NuttX to develop real 
products.

Actual NuttX users all have their own build and CI verify infrastructure 
accustomed to current NuttX build system and doing this causes lots of work for 
little or no rewards.

Just maintaining dozens of customer project external board files in dozens of 
git repositories and dealing with breaking changes between nuttx and apps 
repositories with custom applications and boards is enough work.

Best Regards,
  Juha


From: Sebastien Lorquet 
Sent: Wednesday, June 9, 2021 4:38 PM
To: dev@nuttx.apache.org 
Subject: Re: [Discuss] Migrate the build system to CMake

Hello,

I believe in a stong principle, applied successfully numerous time in my
embedded development company:


It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary in
the first place

- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external
tool with bugs in itself, and its idiosyncrasies and workarounds.


Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of the
nuttx documentation will become fully obsolete overnight.


Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because
anyone can bring it change without a single damn given to customer since
the code has no warranty of fitness of etc etc open source legalese.


If it was me, I would not do this change. If I had to take a decision
about something similar in my company, it would be a strong no.


Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :
> Hi everyone,
>
> this thread has received little engagement from the community
> in general, for a change with such impact on daily use of NuttX
> for everyone.
>
> While there was positive feedback on GH and a few people have
> expressed more interest, not much has really happened. Meanwhile,
> the backlog of changes that would need to be backported continues
> to increase.
>
> At the same time, I see many PRs addressing subtle issues with
> current build system, which are mostly already solved with the migration
> to CMake. So there's continued effort in maintaining the current system
> which could be in part dedicated to the migration to a better system.
>
> I have offered technical guidance on testing and extending to other
> platforms and also to add base support for other arch's so that the focus
> can be put mostly at the board level and on test and validation on different
> platforms and target hardware. However, after having worked on this
> for more than a month I feel this is not really picking up the interest it
> requires for proper adoption by the community.
>
> Maybe the proper approach would be to call on a vote (*)
> for this feature to have explicit support from the community and
> ensure involvement from others than me to move forward.
> Otherwise, or if the vote does not pass, I will not be pushing forward with 
> this.
>
> (*) As a commiter (non-PPMC member), I'm not sure if I can formally call on
> a vote and what the exact procedure is, but maybe other PPMC member
> can do so.
>
> Best,
> Matias
>
> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
>> I am interested and I'll try to help with boards I can test. It will take a
>> few days to get around to it because this has been a busy month, but I'm
>> catching up.
>>
>> Cheers
>> Nathan
>>
>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis > >
>> wrote:
>>
>>> I think we can divide the effort to port all the boards to the new CMake.
>>>
>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>
>>> Let see if we get more people involved in this effort.
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:
 Hi,
 just wanted to add that until this is ready, the gap between master and
>>> the
 branch
 widens with every merged PR and this increases the backporting effort.
 I'm willing to do most of the remaining work but as I mentioned I cannot
 possibly test everything so
 help is needed.
 I'd really like your feedback on this before I continue and ensure the
 effort will not go to waste.

 Best,
 Matias

 On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> Hi,
> for anyone not following the relevant PR, please have a look at the
> current state here:
>
> 

Re: [Discuss] Migrate the build system to CMake

[Gregory Nutt]

Opponents should raise their voice.

They are part of this "community" and have the ability to weight in 
this decision. 


My case may be different.  It is difficult to relinquish control of a 
project and I am training myself to not care so much about anything that 
happens in the project (which is difficult after being so passionate for 
so many years).  But it really is not my responsibility any more.  If 
people want CMake and are willing do all of the work, then they shall 
have CMake.

Re: [Discuss] Migrate the build system to CMake

[Matias N.]

On Wed, Jun 9, 2021, at 11:08, Nathan Hartman wrote:
> On Wed, Jun 9, 2021 at 10:01 AM  > wrote:
> >
> > I like the cmake idea but we should also consider that cmake will have 
> > implications on all projects that use the NuttX as a base for the SDK or 
> > custom projects.
> >
> > All those projects are using the old make system and such a change will 
> > have a huge impact for them.
> 
> 
> This might be a dumb question but:
> 
> Can't a CMake build be an OPTIONAL component for people who want to use it?
> 
> Nathan

Maintaining two build systems in parallel does not really make sense to me. 
There should be only one and used and maintained by the community.

Re: [Discuss] Migrate the build system to CMake

[Nathan Hartman]

On Wed, Jun 9, 2021 at 10:01 AM  wrote:
>
> I like the cmake idea but we should also consider that cmake will have 
> implications on all projects that use the NuttX as a base for the SDK or 
> custom projects.
>
> All those projects are using the old make system and such a change will have 
> a huge impact for them.


This might be a dumb question but:

Can't a CMake build be an OPTIONAL component for people who want to use it?

Nathan

RE: [Discuss] Migrate the build system to CMake

[Alin.Jerpelea]

I like the cmake idea but we should also consider that cmake will have 
implications on all projects that use the NuttX as a base for the SDK or custom 
projects. 

All those projects are using the old make system and such a change will have a 
huge impact for them.

Regards
Alin


-Original Message-
From: Sebastien Lorquet  
Sent: den 9 juni 2021 15:57
To: dev@nuttx.apache.org
Subject: Re: [Discuss] Migrate the build system to CMake

Opponents should raise their voice.

They are part of this "community" and have the ability to weight in this 
decision.

Sebastien

Le 09/06/2021 à 15:46, Gregory Nutt a écrit :
> I think that there a lot of people like myself who are opposed to the 
> CMake change but are remain silent to let the community make the 
> decision.  I suspect that the advocates of CMake are having a larger 
> voice in the decision.
>
> On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
>> Hello,
>>
>> I believe in a stong principle, applied successfully numerous time in 
>> my embedded development company:
>>
>>
>> It it's not broken, dont fix it.
>>
>>
>> That applies precisely to this change.
>>
>> The build system we have have the following characteristics
>>
>> -it works for its intended purposes
>>
>> -it is pretty complex
>>
>> -ALL USERS have become used to it
>>
>>
>> Changing it
>>
>> - will bring a lot of new bugs
>>
>> - along with the annoying feeling that these bugs were not necessary 
>> in the first place
>>
>> - No one will understand the build system anymore
>>
>> - since makefiles are now generated, we rely on yet another external 
>> tool with bugs in itself, and its idiosyncrasies and workarounds.
>>
>>
>> Moreover:
>>
>> -the doc about nuttx is not hosted by the nuttx project, so 99 % of 
>> the nuttx documentation will become fully obsolete overnight.
>>
>>
>> Gratuitous changes are a hell, they destroy efficiency.
>>
>> They tend to appear more frequently in open source projects, because 
>> anyone can bring it change without a single damn given to customer 
>> since the code has no warranty of fitness of etc etc open source 
>> legalese.
>>
>>
>> If it was me, I would not do this change. If I had to take a decision 
>> about something similar in my company, it would be a strong no.
>>
>>
>> Sebastien
>>
>>
>> Le 09/06/2021 à 14:57, Matias N. a écrit :
>>> Hi everyone,
>>>
>>> this thread has received little engagement from the community in 
>>> general, for a change with such impact on daily use of NuttX for 
>>> everyone.
>>>
>>> While there was positive feedback on GH and a few people have 
>>> expressed more interest, not much has really happened. Meanwhile, 
>>> the backlog of changes that would need to be backported continues to 
>>> increase.
>>>
>>> At the same time, I see many PRs addressing subtle issues with 
>>> current build system, which are mostly already solved with the 
>>> migration to CMake. So there's continued effort in maintaining the 
>>> current system which could be in part dedicated to the migration to 
>>> a better system.
>>>
>>> I have offered technical guidance on testing and extending to other 
>>> platforms and also to add base support for other arch's so that the 
>>> focus can be put mostly at the board level and on test and 
>>> validation on different platforms and target hardware. However, 
>>> after having worked on this for more than a month I feel this is not 
>>> really picking up the interest it requires for proper adoption by 
>>> the community.
>>>
>>> Maybe the proper approach would be to call on a vote (*) for this 
>>> feature to have explicit support from the community and ensure 
>>> involvement from others than me to move forward.
>>> Otherwise, or if the vote does not pass, I will not be pushing 
>>> forward with this.
>>>
>>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally 
>>> call on a vote and what the exact procedure is, but maybe other PPMC 
>>> member can do so.
>>>
>>> Best,
>>> Matias
>>>
>>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
 I am interested and I'll try to help with boards I can test. It 
 will take a few days to get around to it because this has been a 
 busy month, but I'm catching up.

 Cheers
 Nathan

 On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis 
 mailto:acassis%40gmail.com>>
 wrote:

> I think we can divide the effort to port all the boards to the new 
> CMake.
>
> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>
> Let see if we get more people involved in this effort.
>
> BR,
>
> Alan
>
> On 6/1/21, Matias N. mailto:matias%40imap.cc>>
> wrote:
>> Hi,
>> just wanted to add that until this is ready, the gap between 
>> master and
> the
>> branch
>> widens with every merged PR and this increases the backporting 
>> effort.
>> I'm willing to do most of the remaining work but as I mentioned I 
>> cannot possibly test 

Re: [Discuss] Migrate the build system to CMake

[Sebastien Lorquet]

Opponents should raise their voice.

They are part of this "community" and have the ability to weight in this 
decision.


Sebastien

Le 09/06/2021 à 15:46, Gregory Nutt a écrit :
I think that there a lot of people like myself who are opposed to the 
CMake change but are remain silent to let the community make the 
decision.  I suspect that the advocates of CMake are having a larger 
voice in the decision.


On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:

Hello,

I believe in a stong principle, applied successfully numerous time in 
my embedded development company:



It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary 
in the first place


- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external 
tool with bugs in itself, and its idiosyncrasies and workarounds.



Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of 
the nuttx documentation will become fully obsolete overnight.



Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because 
anyone can bring it change without a single damn given to customer 
since the code has no warranty of fitness of etc etc open source 
legalese.



If it was me, I would not do this change. If I had to take a decision 
about something similar in my company, it would be a strong no.



Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the 
migration

to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the 
focus
can be put mostly at the board level and on test and validation on 
different

platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the 
interest it

requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing 
forward with this.


(*) As a commiter (non-PPMC member), I'm not sure if I can formally 
call on

a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
I am interested and I'll try to help with boards I can test. It 
will take a
few days to get around to it because this has been a busy month, 
but I'm

catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis 
mailto:acassis%40gmail.com>>

wrote:

I think we can divide the effort to port all the boards to the new 
CMake.


I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N. mailto:matias%40imap.cc>> 
wrote:

Hi,
just wanted to add that until this is ready, the gap between 
master and

the

branch
widens with every merged PR and this increases the backporting 
effort.
I'm willing to do most of the remaining work but as I mentioned I 
cannot

possibly test everything so
help is needed.
I'd really like your feedback on this before I continue and 
ensure the

effort will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:

Hi,
for anyone not following the relevant PR, please have a look at the
current state here:

https://github.com/apache/incubator-nuttx/pull/3704

This is now at a point where it can be tested by others. It 
would be

very

good to get some
help testing what I got so far (sim and stm32f4discovery, both 
on Linux

and mac), by running
examples and test. There are some brief instructions at the end 
of the

PR

description for building.

Other than that, I can continue porting other arch's and boards 
with the

help of CI but it would be
best if others with more boards could help testing (and ideally 
with

some

PRs, as the hard part
is mostly done) those as well.

Also, note that this is a PR against a branch so we 

Re: [Discuss] Migrate the build system to CMake

[Gregory Nutt]

I think that there a lot of people like myself who are opposed to the 
CMake change but are remain silent to let the community make the 
decision.  I suspect that the advocates of CMake are having a larger 
voice in the decision.


On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:

Hello,

I believe in a stong principle, applied successfully numerous time in 
my embedded development company:



It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary 
in the first place


- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external 
tool with bugs in itself, and its idiosyncrasies and workarounds.



Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of 
the nuttx documentation will become fully obsolete overnight.



Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because 
anyone can bring it change without a single damn given to customer 
since the code has no warranty of fitness of etc etc open source 
legalese.



If it was me, I would not do this change. If I had to take a decision 
about something similar in my company, it would be a strong no.



Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the migration
to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the 
focus
can be put mostly at the board level and on test and validation on 
different

platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the 
interest it

requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing 
forward with this.


(*) As a commiter (non-PPMC member), I'm not sure if I can formally 
call on

a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
I am interested and I'll try to help with boards I can test. It will 
take a
few days to get around to it because this has been a busy month, but 
I'm

catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis 
mailto:acassis%40gmail.com>>

wrote:

I think we can divide the effort to port all the boards to the new 
CMake.


I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:

Hi,
just wanted to add that until this is ready, the gap between 
master and

the

branch
widens with every merged PR and this increases the backporting 
effort.
I'm willing to do most of the remaining work but as I mentioned I 
cannot

possibly test everything so
help is needed.
I'd really like your feedback on this before I continue and ensure 
the

effort will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:

Hi,
for anyone not following the relevant PR, please have a look at the
current state here:

https://github.com/apache/incubator-nuttx/pull/3704

This is now at a point where it can be tested by others. It would be

very

good to get some
help testing what I got so far (sim and stm32f4discovery, both on 
Linux

and mac), by running
examples and test. There are some brief instructions at the end 
of the

PR

description for building.

Other than that, I can continue porting other arch's and boards 
with the

help of CI but it would be
best if others with more boards could help testing (and ideally with

some

PRs, as the hard part
is mostly done) those as well.

Also, note that this is a PR against a branch so we could eventually

merge

it before adding support
for other arch/boards. And finally, I will provide documentation 
to the

new build system in a separate
PR at some point, which I hope 

Re: [Discuss] Migrate the build system to CMake

[Sebastien Lorquet]

Hello,

I believe in a stong principle, applied successfully numerous time in my 
embedded development company:



It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary in 
the first place


- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external 
tool with bugs in itself, and its idiosyncrasies and workarounds.



Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of the 
nuttx documentation will become fully obsolete overnight.



Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because 
anyone can bring it change without a single damn given to customer since 
the code has no warranty of fitness of etc etc open source legalese.



If it was me, I would not do this change. If I had to take a decision 
about something similar in my company, it would be a strong no.



Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the migration
to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the focus
can be put mostly at the board level and on test and validation on different
platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the interest it
requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing forward with 
this.

(*) As a commiter (non-PPMC member), I'm not sure if I can formally call on
a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:

I am interested and I'll try to help with boards I can test. It will take a
few days to get around to it because this has been a busy month, but I'm
catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis mailto:acassis%40gmail.com>>
wrote:


I think we can divide the effort to port all the boards to the new CMake.

I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:

Hi,
just wanted to add that until this is ready, the gap between master and

the

branch
widens with every merged PR and this increases the backporting effort.
I'm willing to do most of the remaining work but as I mentioned I cannot
possibly test everything so
help is needed.
I'd really like your feedback on this before I continue and ensure the
effort will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:

Hi,
for anyone not following the relevant PR, please have a look at the
current state here:

https://github.com/apache/incubator-nuttx/pull/3704

This is now at a point where it can be tested by others. It would be

very

good to get some
help testing what I got so far (sim and stm32f4discovery, both on Linux
and mac), by running
examples and test. There are some brief instructions at the end of the

PR

description for building.

Other than that, I can continue porting other arch's and boards with the
help of CI but it would be
best if others with more boards could help testing (and ideally with

some

PRs, as the hard part
is mostly done) those as well.

Also, note that this is a PR against a branch so we could eventually

merge

it before adding support
for other arch/boards. And finally, I will provide documentation to the
new build system in a separate
PR at some point, which I hope will ease the transition and help
reviewing.

Best,
Matias

On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:

A new issue is opened recently to address this topic:
https://github.com/apache/incubator-nuttx/issues/3455
This proposal has the depth of the impact in our daily working, so it's
very important 

Re: [Discuss] Migrate the build system to CMake

[Matias N.]

Hi Alan,

On Wed, Jun 9, 2021, at 10:12, Alan Carvalho de Assis wrote:
> Hi Matias,
> 
> I think according to Apache rules anyone can call for vote.

Ok. I would imagine that for a vote to have any purpose there
still needs to be some discussion first. Or is it ok to have the discussion
on the vote thread?

My proposal to vote on would be to:
- confirm interest over this change by the community
- discuss potential roadmap for completing the work on the cmake branch
and integration of the branch into master
- identify community members willing to support the effort and organize
in a table who would test on which platform and which target to ensure 
sufficient
coverage

> I'm working in the ESP32(C3, S2) cmake port and probably will need your 
> review.

Sure, thanks. I know you volunteered and I appreciate it. But I think
we need larger commitment from other people as well due to the
large number of arch/boards/platforms supported.

> Moving from Makefile to CMake is not a simple task and it is prone for
> failure, OpenOCD tried it around 2008 or so and it didn't get to much
> traction, so the end up with Makefiles until now.

The current state of the migration is quite usable and I focused on critical 
aspects
such as the protected build, ELF modules, etc. This has helped me identify
the tricky bits. The remaining work should not be that hard as it is mostly
covering new platforms and most of the ground work is laid out.

> I think it is important to reinforce the benefit we will get from
> CMake, otherwise people will still with Makefile, because it is a
> "known devil".

This was already done on the original GitHub issue (which was linked
at the top of the thread):

https://github.com/apache/incubator-nuttx/issues/3455

Best,
Matias

> 
> BR,
> 
> Alan
> 
> On 6/9/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > Hi everyone,
> >
> > this thread has received little engagement from the community
> > in general, for a change with such impact on daily use of NuttX
> > for everyone.
> >
> > While there was positive feedback on GH and a few people have
> > expressed more interest, not much has really happened. Meanwhile,
> > the backlog of changes that would need to be backported continues
> > to increase.
> >
> > At the same time, I see many PRs addressing subtle issues with
> > current build system, which are mostly already solved with the migration
> > to CMake. So there's continued effort in maintaining the current system
> > which could be in part dedicated to the migration to a better system.
> >
> > I have offered technical guidance on testing and extending to other
> > platforms and also to add base support for other arch's so that the focus
> > can be put mostly at the board level and on test and validation on
> > different
> > platforms and target hardware. However, after having worked on this
> > for more than a month I feel this is not really picking up the interest it
> > requires for proper adoption by the community.
> >
> > Maybe the proper approach would be to call on a vote (*)
> > for this feature to have explicit support from the community and
> > ensure involvement from others than me to move forward.
> > Otherwise, or if the vote does not pass, I will not be pushing forward with
> > this.
> >
> > (*) As a commiter (non-PPMC member), I'm not sure if I can formally call on
> > a vote and what the exact procedure is, but maybe other PPMC member
> > can do so.
> >
> > Best,
> > Matias
> >
> > On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
> >> I am interested and I'll try to help with boards I can test. It will take
> >> a
> >> few days to get around to it because this has been a busy month, but I'm
> >> catching up.
> >>
> >> Cheers
> >> Nathan
> >>
> >> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis  >> 
> >> >
> >> wrote:
> >>
> >> > I think we can divide the effort to port all the boards to the new
> >> > CMake.
> >> >
> >> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> >> >
> >> > Let see if we get more people involved in this effort.
> >> >
> >> > BR,
> >> >
> >> > Alan
> >> >
> >> > On 6/1/21, Matias N. mailto:matias%40imap.cc> 
> >> > > wrote:
> >> > > Hi,
> >> > > just wanted to add that until this is ready, the gap between master
> >> > > and
> >> > the
> >> > > branch
> >> > > widens with every merged PR and this increases the backporting
> >> > > effort.
> >> > > I'm willing to do most of the remaining work but as I mentioned I
> >> > > cannot
> >> > > possibly test everything so
> >> > > help is needed.
> >> > > I'd really like your feedback on this before I continue and ensure
> >> > > the
> >> > > effort will not go to waste.
> >> > >
> >> > > Best,
> >> > > Matias
> >> > >
> >> > > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> >> > >> Hi,
> >> > >> for anyone not following the relevant PR, please have a look at the
> >> > >> current state here:
> >> > >>
> >> > >> 

Re: [Discuss] Migrate the build system to CMake

[Alan Carvalho de Assis]

Hi Matias,

I think according to Apache rules anyone can call for vote.

I'm working in the ESP32(C3, S2) cmake port and probably will need your review.

Moving from Makefile to CMake is not a simple task and it is prone for
failure, OpenOCD tried it around 2008 or so and it didn't get to much
traction, so the end up with Makefiles until now.

I think it is important to reinforce the benefit we will get from
CMake, otherwise people will still with Makefile, because it is a
"known devil".

BR,

Alan

On 6/9/21, Matias N.  wrote:
> Hi everyone,
>
> this thread has received little engagement from the community
> in general, for a change with such impact on daily use of NuttX
> for everyone.
>
> While there was positive feedback on GH and a few people have
> expressed more interest, not much has really happened. Meanwhile,
> the backlog of changes that would need to be backported continues
> to increase.
>
> At the same time, I see many PRs addressing subtle issues with
> current build system, which are mostly already solved with the migration
> to CMake. So there's continued effort in maintaining the current system
> which could be in part dedicated to the migration to a better system.
>
> I have offered technical guidance on testing and extending to other
> platforms and also to add base support for other arch's so that the focus
> can be put mostly at the board level and on test and validation on
> different
> platforms and target hardware. However, after having worked on this
> for more than a month I feel this is not really picking up the interest it
> requires for proper adoption by the community.
>
> Maybe the proper approach would be to call on a vote (*)
> for this feature to have explicit support from the community and
> ensure involvement from others than me to move forward.
> Otherwise, or if the vote does not pass, I will not be pushing forward with
> this.
>
> (*) As a commiter (non-PPMC member), I'm not sure if I can formally call on
> a vote and what the exact procedure is, but maybe other PPMC member
> can do so.
>
> Best,
> Matias
>
> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
>> I am interested and I'll try to help with boards I can test. It will take
>> a
>> few days to get around to it because this has been a busy month, but I'm
>> catching up.
>>
>> Cheers
>> Nathan
>>
>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis > >
>> wrote:
>>
>> > I think we can divide the effort to port all the boards to the new
>> > CMake.
>> >
>> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>> >
>> > Let see if we get more people involved in this effort.
>> >
>> > BR,
>> >
>> > Alan
>> >
>> > On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:
>> > > Hi,
>> > > just wanted to add that until this is ready, the gap between master
>> > > and
>> > the
>> > > branch
>> > > widens with every merged PR and this increases the backporting
>> > > effort.
>> > > I'm willing to do most of the remaining work but as I mentioned I
>> > > cannot
>> > > possibly test everything so
>> > > help is needed.
>> > > I'd really like your feedback on this before I continue and ensure
>> > > the
>> > > effort will not go to waste.
>> > >
>> > > Best,
>> > > Matias
>> > >
>> > > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>> > >> Hi,
>> > >> for anyone not following the relevant PR, please have a look at the
>> > >> current state here:
>> > >>
>> > >> https://github.com/apache/incubator-nuttx/pull/3704
>> > >>
>> > >> This is now at a point where it can be tested by others. It would be
>> > very
>> > >> good to get some
>> > >> help testing what I got so far (sim and stm32f4discovery, both on
>> > >> Linux
>> > >> and mac), by running
>> > >> examples and test. There are some brief instructions at the end of
>> > >> the
>> > PR
>> > >> description for building.
>> > >>
>> > >> Other than that, I can continue porting other arch's and boards with
>> > >> the
>> > >> help of CI but it would be
>> > >> best if others with more boards could help testing (and ideally with
>> > some
>> > >> PRs, as the hard part
>> > >> is mostly done) those as well.
>> > >>
>> > >> Also, note that this is a PR against a branch so we could eventually
>> > merge
>> > >> it before adding support
>> > >> for other arch/boards. And finally, I will provide documentation to
>> > >> the
>> > >> new build system in a separate
>> > >> PR at some point, which I hope will ease the transition and help
>> > >> reviewing.
>> > >>
>> > >> Best,
>> > >> Matias
>> > >>
>> > >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>> > >>> A new issue is opened recently to address this topic:
>> > >>> https://github.com/apache/incubator-nuttx/issues/3455
>> > >>> This proposal has the depth of the impact in our daily working, so
>> > >>> it's
>> > >>> very important to get the feedback from the community before the
>> > >>> real
>> > >>> action is taken.
>> > >>> If you have any concern or suggestion, please reply to 

Re: [Discuss] Migrate the build system to CMake

[Matias N.]

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the migration
to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the focus
can be put mostly at the board level and on test and validation on different
platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the interest it
requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing forward with 
this.

(*) As a commiter (non-PPMC member), I'm not sure if I can formally call on
a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
> I am interested and I'll try to help with boards I can test. It will take a
> few days to get around to it because this has been a busy month, but I'm
> catching up.
> 
> Cheers
> Nathan
> 
> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis  >
> wrote:
> 
> > I think we can divide the effort to port all the boards to the new CMake.
> >
> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> >
> > Let see if we get more people involved in this effort.
> >
> > BR,
> >
> > Alan
> >
> > On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > > Hi,
> > > just wanted to add that until this is ready, the gap between master and
> > the
> > > branch
> > > widens with every merged PR and this increases the backporting effort.
> > > I'm willing to do most of the remaining work but as I mentioned I cannot
> > > possibly test everything so
> > > help is needed.
> > > I'd really like your feedback on this before I continue and ensure the
> > > effort will not go to waste.
> > >
> > > Best,
> > > Matias
> > >
> > > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> > >> Hi,
> > >> for anyone not following the relevant PR, please have a look at the
> > >> current state here:
> > >>
> > >> https://github.com/apache/incubator-nuttx/pull/3704
> > >>
> > >> This is now at a point where it can be tested by others. It would be
> > very
> > >> good to get some
> > >> help testing what I got so far (sim and stm32f4discovery, both on Linux
> > >> and mac), by running
> > >> examples and test. There are some brief instructions at the end of the
> > PR
> > >> description for building.
> > >>
> > >> Other than that, I can continue porting other arch's and boards with the
> > >> help of CI but it would be
> > >> best if others with more boards could help testing (and ideally with
> > some
> > >> PRs, as the hard part
> > >> is mostly done) those as well.
> > >>
> > >> Also, note that this is a PR against a branch so we could eventually
> > merge
> > >> it before adding support
> > >> for other arch/boards. And finally, I will provide documentation to the
> > >> new build system in a separate
> > >> PR at some point, which I hope will ease the transition and help
> > >> reviewing.
> > >>
> > >> Best,
> > >> Matias
> > >>
> > >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> > >>> A new issue is opened recently to address this topic:
> > >>> https://github.com/apache/incubator-nuttx/issues/3455
> > >>> This proposal has the depth of the impact in our daily working, so it's
> > >>> very important to get the feedback from the community before the real
> > >>> action is taken.
> > >>> If you have any concern or suggestion, please reply to this email.
> > >>>
> > >>> Thanks
> > >>> Xiang
> > >>>
> > >>
> > >
> >
> 

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Matias N.]

Hi Miguel,

if you have questions regarding using nimBLE I suggest you go to their
support channels as this is really not NuttX related.

Best,
Matias

On Tue, Jun 8, 2021, at 14:01, Miguel Wisintainer wrote:
> Hi Matias

>  

> Have you some example to make the scan ?

>  

> Enviado do Email  para 
> Windows 10

>