You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Xiang Xiao <xi...@gmail.com> on 2021/04/10 21:43:51 UTC
[Discuss] Migrate the build system to CMake
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: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
On Tue, Jun 1, 2021, at 12:24, Alan Carvalho de Assis wrote:
> I think we can divide the effort to port all the boards to the new CMake.
That would be ideal.
> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>
> Let see if we get more people involved in this effort.
Thanks, Alan.
>
> BR,
>
> Alan
>
> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
> > Hi,
> > just wanted to add that until this is ready, the gap between master and the
> > branch
> > widens with every merged PR and this increases the backporting effort.
> > I'm willing to do most of the remaining work but as I mentioned I cannot
> > possibly test everything so
> > help is needed.
> > I'd really like your feedback on this before I continue and ensure the
> > effort will not go to waste.
> >
> > Best,
> > Matias
> >
> > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> >> Hi,
> >> for anyone not following the relevant PR, please have a look at the
> >> current state here:
> >>
> >> https://github.com/apache/incubator-nuttx/pull/3704
> >>
> >> This is now at a point where it can be tested by others. It would be very
> >> good to get some
> >> help testing what I got so far (sim and stm32f4discovery, both on Linux
> >> and mac), by running
> >> examples and test. There are some brief instructions at the end of the PR
> >> description for building.
> >>
> >> Other than that, I can continue porting other arch's and boards with the
> >> help of CI but it would be
> >> best if others with more boards could help testing (and ideally with some
> >> PRs, as the hard part
> >> is mostly done) those as well.
> >>
> >> Also, note that this is a PR against a branch so we could eventually merge
> >> it before adding support
> >> for other arch/boards. And finally, I will provide documentation to the
> >> new build system in a separate
> >> PR at some point, which I hope will ease the transition and help
> >> reviewing.
> >>
> >> Best,
> >> Matias
> >>
> >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> >>> A new issue is opened recently to address this topic:
> >>> https://github.com/apache/incubator-nuttx/issues/3455
> >>> This proposal has the depth of the impact in our daily working, so it's
> >>> very important to get the feedback from the community before the real
> >>> action is taken.
> >>> If you have any concern or suggestion, please reply to this email.
> >>>
> >>> Thanks
> >>> Xiang
> >>>
> >>
> >
>
Re: [Discuss] Migrate the build system to CMake
Posted by "Juha Niskanen (Haltian)" <ju...@haltian.com>.
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 <se...@lorquet.fr>
Sent: Wednesday, June 9, 2021 4:38 PM
To: dev@nuttx.apache.org <de...@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 <acassis@gmail.com <mailto:acassis%40gmail.com>>
>> wrote:
>>
>>> I think we can divide the effort to port all the boards to the new CMake.
>>>
>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>
>>> Let see if we get more people involved in this effort.
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
>>>> Hi,
>>>> just wanted to add that until this is ready, the gap between master and
>>> the
>>>> branch
>>>> widens with every merged PR and this increases the backporting effort.
>>>> I'm willing to do most of the remaining work but as I mentioned I cannot
>>>> possibly test everything so
>>>> help is needed.
>>>> I'd really like your feedback on this before I continue and ensure the
>>>> effort will not go to waste.
>>>>
>>>> Best,
>>>> Matias
>>>>
>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>>>>> Hi,
>>>>> for anyone not following the relevant PR, please have a look at the
>>>>> current state here:
>>>>>
>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-nuttx%2Fpull%2F3704&data=04%7C01%7Cjuha.niskanen%40haltian.com%7C8f1a6fc871d44899bc6308d92b4be967%7C2f7c629267f24cc582be5d187e289ab2%7C1%7C0%7C637588427316160451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WLeZN5VF3Ocr89oqSQxiDRy%2F7OYOU3btIPTimKqXhGI%3D&reserved=0
>>>>>
>>>>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-nuttx%2Fissues%2F3455&data=04%7C01%7Cjuha.niskanen%40haltian.com%7C8f1a6fc871d44899bc6308d92b4be967%7C2f7c629267f24cc582be5d187e289ab2%7C1%7C0%7C637588427316160451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eorBeLu4%2BqCiwA%2BTTRTFnwwVqB1v9iifpzEZwPfbJ74%3D&reserved=0
>>>>>> 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: [Discuss] Migrate the build system to CMake
Posted by Gregory Nutt <sp...@gmail.com>.
> 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
Posted by "Matias N." <ma...@imap.cc>.
On Wed, Jun 9, 2021, at 11:08, Nathan Hartman wrote:
> On Wed, Jun 9, 2021 at 10:01 AM <Alin.Jerpelea@sony.com <mailto:Alin.Jerpelea%40sony.com>> 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
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Jun 9, 2021 at 10:01 AM <Al...@sony.com> 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
Posted by Al...@sony.com.
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 <se...@lorquet.fr>
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
>>>> <acassis@gmail.com <mailto:acassis%40gmail.com>>
>>>> wrote:
>>>>
>>>>> I think we can divide the effort to port all the boards to the new
>>>>> CMake.
>>>>>
>>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>>>
>>>>> Let see if we get more people involved in this effort.
>>>>>
>>>>> BR,
>>>>>
>>>>> Alan
>>>>>
>>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>>
>>>>> wrote:
>>>>>> Hi,
>>>>>> just wanted to add that until this is ready, the gap between
>>>>>> master and
>>>>> the
>>>>>> branch
>>>>>> widens with every merged PR and this increases the backporting
>>>>>> effort.
>>>>>> I'm willing to do most of the remaining work but as I mentioned I
>>>>>> cannot possibly test everything so help is needed.
>>>>>> I'd really like your feedback on this before I continue and
>>>>>> ensure the effort will not go to waste.
>>>>>>
>>>>>> Best,
>>>>>> Matias
>>>>>>
>>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>>>>>>> Hi,
>>>>>>> for anyone not following the relevant PR, please have a look at
>>>>>>> the current state here:
>>>>>>>
>>>>>>> https://urldefense.com/v3/__https://github.com/apache/incubator-
>>>>>>> nuttx/pull/3704__;!!JmoZiZGBv3RvKRSx!tcmt44RO4Rbmk83X7adyRGP8Xsn
>>>>>>> fjZ0KpZeVi47Rt1jvUe3UNJT8qcnIRbMl5wvAfA$
>>>>>>>
>>>>>>> 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://urldefense.com/v3/__https://github.com/apache/incubator
>>>>>>>> -nuttx/issues/3455__;!!JmoZiZGBv3RvKRSx!tcmt44RO4Rbmk83X7adyRGP
>>>>>>>> 8XsnfjZ0KpZeVi47Rt1jvUe3UNJT8qcnIRbNvEaLWow$
>>>>>>>> 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: [Discuss] Migrate the build system to CMake
Posted by Sebastien Lorquet <se...@lorquet.fr>.
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
>>>> <acassis@gmail.com <mailto:acassis%40gmail.com>>
>>>> wrote:
>>>>
>>>>> I think we can divide the effort to port all the boards to the new
>>>>> CMake.
>>>>>
>>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>>>
>>>>> Let see if we get more people involved in this effort.
>>>>>
>>>>> BR,
>>>>>
>>>>> Alan
>>>>>
>>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>>
>>>>> wrote:
>>>>>> Hi,
>>>>>> just wanted to add that until this is ready, the gap between
>>>>>> master and
>>>>> the
>>>>>> branch
>>>>>> widens with every merged PR and this increases the backporting
>>>>>> effort.
>>>>>> I'm willing to do most of the remaining work but as I mentioned I
>>>>>> cannot
>>>>>> possibly test everything so
>>>>>> help is needed.
>>>>>> I'd really like your feedback on this before I continue and
>>>>>> ensure the
>>>>>> effort will not go to waste.
>>>>>>
>>>>>> Best,
>>>>>> Matias
>>>>>>
>>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>>>>>>> Hi,
>>>>>>> for anyone not following the relevant PR, please have a look at the
>>>>>>> current state here:
>>>>>>>
>>>>>>> https://github.com/apache/incubator-nuttx/pull/3704
>>>>>>>
>>>>>>> This is now at a point where it can be tested by others. It
>>>>>>> would be
>>>>> very
>>>>>>> good to get some
>>>>>>> help testing what I got so far (sim and stm32f4discovery, both
>>>>>>> on Linux
>>>>>>> and mac), by running
>>>>>>> examples and test. There are some brief instructions at the end
>>>>>>> of the
>>>>> PR
>>>>>>> description for building.
>>>>>>>
>>>>>>> Other than that, I can continue porting other arch's and boards
>>>>>>> with the
>>>>>>> help of CI but it would be
>>>>>>> best if others with more boards could help testing (and ideally
>>>>>>> with
>>>>> some
>>>>>>> PRs, as the hard part
>>>>>>> is mostly done) those as well.
>>>>>>>
>>>>>>> Also, note that this is a PR against a branch so we could
>>>>>>> eventually
>>>>> merge
>>>>>>> it before adding support
>>>>>>> for other arch/boards. And finally, I will provide documentation
>>>>>>> to the
>>>>>>> new build system in a separate
>>>>>>> PR at some point, which I hope will ease the transition and help
>>>>>>> reviewing.
>>>>>>>
>>>>>>> Best,
>>>>>>> Matias
>>>>>>>
>>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>>>>>>>> A new issue is opened recently to address this topic:
>>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
>>>>>>>> This proposal has the depth of the impact in our daily working,
>>>>>>>> so it's
>>>>>>>> very important to get the feedback from the community before
>>>>>>>> the real
>>>>>>>> action is taken.
>>>>>>>> If you have any concern or suggestion, please reply to this email.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Xiang
>>>>>>>>
>
Re: [Discuss] Migrate the build system to CMake
Posted by Maciej Wójcik <w8...@gmail.com>.
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 shouldn't scrap what
you did so far.
There is one dream about NuttX that I was trying to accomplish a few times.
To have some packaging system like npm/cargo/pip and a website where
people can submit their applications to share them with others. For this
additional standardisation is needed. CMake offers standardisation and
beter modularisation. I was waiting for your solution to try again.
Don't like CMake but it is good, it works. I was searching hard but
couldn't find
anything better than this. Make is primitive. It would be simple and
transparent,
but it is already not, because of the size and complexity of NuttX code
base.
So I don't see a reason why stick to it. I fully understood why Greg didn't
want it
a few years ago. But I don't understand why there is so much opposition now.
Finally, what other projects like Zephyr or ESP-SDK are using. It is CMake
isn't it?
People behind them must be very unreasonable to do so.
Am Mi., 9. Juni 2021 um 22:09 Uhr schrieb David S. Alessio <
david.s.alessio@gmail.com>:
>
>
> > On Jun 9, 2021, at 12:20 PM, Brennan Ashton <ba...@brennanashton.com>
> wrote:
> >
> > On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos <f.j.panag@gmail.com
> >
> > 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
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
> 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 <da...@gmail.com>
wrote:
>
>
> > On Jun 9, 2021, at 12:20 PM, Brennan Ashton <ba...@brennanashton.com>
> wrote:
> >
> > On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos <f.j.panag@gmail.com
> >
> > 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
Posted by "David S. Alessio" <da...@gmail.com>.
> On Jun 9, 2021, at 12:20 PM, Brennan Ashton <ba...@brennanashton.com> wrote:
>
> On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos <f....@gmail.com>
> 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
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Wed, Jun 9, 2021, 11:04 AM Fotis Panagiotopoulos <f....@gmail.com>
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
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
Hello Guys,
In my specific situation, I use NuttX separately from the application,
deployed as a library.
And I use CMake to build my application. My reason to choose CMake was
tool integration and easier support to add other open source
libraries.
CMake can build fast, but make is not slow. In fact, CMake is a
makefile file generator. I use ninja in my builds, but could be make
as well. Probably that's the reason that it works better in different
environments.
Adding another point for the discussion, maybe the build system for
the operating system should not be the same for the application, just
like Linux today. The build system challenge is more relevant if you
have OS and apps together. Considering OS as, somehow, a BSP, then I
don't know what would be the value for changing the build system.
Best regards,
Flavio
Em qui., 10 de jun. de 2021 às 04:50, Sebastien Lorquet
<se...@lorquet.fr> escreveu:
>
> Hello,
>
> Le 10/06/2021 à 02:00, Matias N. a écrit :
> > 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.
>
> I have no doubt that the new build system will work better.
>
> I understand that it builds faster than the existing and requires less
> kludges, and permits out of tree builds.
>
> But it's a fundamental change about how to approach the NuttX OS globally.
>
> The track record of this OS in terms of user documentation is not very
> good, to be honest, it requires a lot of time to dig in various source
> files and different web sites to understand how to do something.
>
> This is not only my experience, it's the feeling of all of the ~10
> persons I have tried to introduce to Nuttx: This OS is hard, it does not
> guide beginners and it's hard to do "WHAT I WANT" (which is usually not
> configuring nsh on a stm32f4discovery, but hands-on use case on custom
> hardware with custom apps).
>
> With that in mind, I am very worried of a supplemental dispersion of
> useful documentation.
>
> At what release/commit does the build system becomes cmake? before that,
> please refer to the make build system documentation. chances are that
> this doc quickly becomes 404, leaving all users of all versions in the
> dark. for commits after that, please refer to this other documentation
> on some personal blog, but only for release a.b.c later than this date.
>
> I dont think cmake is technically wrong, but from a USER POINT OF VIEW,
> it will become a nightmare and will drive new contributors away, because
> of documentation problems.
>
> Not to mention old users who spend weeks just to migrate a few boards
> from an old to a new nuttx, just because a makefile and a critical
> variable were renamed but no migration documentation exists. Add more
> changes, and a project may become unusable in the current state of the
> project.
>
> So please. Keep NuttX interfaces STABLE for users that need it. It's not
> a beta project anymore, it's "mature" as you advertise it, which means
> it has some real industrial users that matter more than abstract
> technical beauty. EXTRADEFINES now also need to include flags. hah, not
> cool. I should rename that to EXTRAFLAGS, thats more cute. But how many
> users will suffer from this apparently benign change? These questions
> NEED to be asked by developers and contributors and reviewers.
>
> When you make a change, please ask yourselves: how many unknown users
> will I f*k up with that?
>
> As a famous quote more or less goes, because it can be done does not
> mean it should be done.
>
> And having a generator that derives cmake files from current makefiles
> feels a bit like xkcd #927
>
> Sebastien
>
--
Flavio de Castro Alves Filho
flavio.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: [Discuss] Migrate the build system to CMake
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jun 10, 2021 at 11:33 AM Sebastien Lorquet <se...@lorquet.fr> wrote:
>
>
> Le 10/06/2021 à 16:34, Nathan Hartman a écrit :
> > Second, we need a new Documentation page, "Migrating From Older
> > NuttX." In this documentation, every compatibility change should be
> > documented, going from the present to at least as far back as NuttX
> > 7.31. We can get all of these from the ReleaseNotes, but they should
> > be consolidated somewhere, so that someone like Sebastien who wants to
> > upgrade from version X to version Y can just go step by step and make
> > the necessary changes.
> That would be an extremely good thing to have. It would ensure an
> exhaustive migration path for legacy installations.
>
> That page should then explain how to migrate to cmake.
>
> If this doc is easy to find, I have less issues with cmake.
>
> Also thank you for fixing the release notes. This triplication is not
> easy to manage.
Agreed, and one of these days I'm sure we'll find a better solution!
In the "Migrating From Older NuttX" document:
The last section should document migrating from Latest Release to
current master's HEAD.
I think it should be the project's policy, from now on, that every
time a breaking change is made, it should be documented in that
section IN THE SAME PR.
This way, everyone will always have documentation how to get from
wherever they are to latest HEAD, and
When we release, all we have to do is change the title of that section
to the new release number, and add a new empty section for HEAD below
that.
Nathan
Re: [Discuss] Migrate the build system to CMake
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Le 10/06/2021 à 16:34, Nathan Hartman a écrit :
> Second, we need a new Documentation page, "Migrating From Older
> NuttX." In this documentation, every compatibility change should be
> documented, going from the present to at least as far back as NuttX
> 7.31. We can get all of these from the ReleaseNotes, but they should
> be consolidated somewhere, so that someone like Sebastien who wants to
> upgrade from version X to version Y can just go step by step and make
> the necessary changes.
That would be an extremely good thing to have. It would ensure an
exhaustive migration path for legacy installations.
That page should then explain how to migrate to cmake.
If this doc is easy to find, I have less issues with cmake.
Also thank you for fixing the release notes. This triplication is not
easy to manage.
Sebastien
Re: [Discuss] Migrate the build system to CMake
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jun 10, 2021 at 11:01 AM Nathan Hartman
<ha...@gmail.com> wrote:
>
> On Thu, Jun 10, 2021 at 10:34 AM Nathan Hartman
> <ha...@gmail.com> wrote:
> > I was in the CWIKI just a few moments ago, to create the skeleton for
> > what will be our next ReleaseNotes, and I found out something
> > unfortunate: In the CWIKI copy of the 9.1 ReleaseNotes [1], the
> > EXTRADEFINES -> EXTRAFLAGS change is documented. BUT... In the repo
> > ReleaseNotes file [2], that section is COMPLETELY MISSING! It is also
> > missing on the website [3]. In fact, all the compatibility docs are
> > missing from both places, such as Rename WINTOOL to
> > CONFIG_CYGWIN_WINTOOL, etc.
> >
> > First, I am going to send a PR to fix the ReleaseNotes in the repo.
>
> Ok that's done. See PR-3897:
> https://github.com/apache/incubator-nuttx/pull/3897
Also PR-57 on the website repo:
https://github.com/apache/incubator-nuttx-website/pull/57
Nathan
Re: [Discuss] Migrate the build system to CMake
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jun 10, 2021 at 10:34 AM Nathan Hartman
<ha...@gmail.com> wrote:
> I was in the CWIKI just a few moments ago, to create the skeleton for
> what will be our next ReleaseNotes, and I found out something
> unfortunate: In the CWIKI copy of the 9.1 ReleaseNotes [1], the
> EXTRADEFINES -> EXTRAFLAGS change is documented. BUT... In the repo
> ReleaseNotes file [2], that section is COMPLETELY MISSING! It is also
> missing on the website [3]. In fact, all the compatibility docs are
> missing from both places, such as Rename WINTOOL to
> CONFIG_CYGWIN_WINTOOL, etc.
>
> First, I am going to send a PR to fix the ReleaseNotes in the repo.
Ok that's done. See PR-3897:
https://github.com/apache/incubator-nuttx/pull/3897
Nathan
Re: [Discuss] Migrate the build system to CMake
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jun 10, 2021 at 3:50 AM Sebastien Lorquet <se...@lorquet.fr> wrote:
> With that in mind, I am very worried of a supplemental dispersion of
> useful documentation.
>
> At what release/commit does the build system becomes cmake? before that,
> please refer to the make build system documentation. chances are that
> this doc quickly becomes 404, leaving all users of all versions in the
> dark. for commits after that, please refer to this other documentation
> on some personal blog, but only for release a.b.c later than this date.
(snip)
> So please. Keep NuttX interfaces STABLE for users that need it. It's not
> a beta project anymore, it's "mature" as you advertise it, which means
> it has some real industrial users that matter more than abstract
> technical beauty. EXTRADEFINES now also need to include flags. hah, not
> cool. I should rename that to EXTRAFLAGS, thats more cute. But how many
> users will suffer from this apparently benign change? These questions
> NEED to be asked by developers and contributors and reviewers.
We screwed up.
I was in the CWIKI just a few moments ago, to create the skeleton for
what will be our next ReleaseNotes, and I found out something
unfortunate: In the CWIKI copy of the 9.1 ReleaseNotes [1], the
EXTRADEFINES -> EXTRAFLAGS change is documented. BUT... In the repo
ReleaseNotes file [2], that section is COMPLETELY MISSING! It is also
missing on the website [3]. In fact, all the compatibility docs are
missing from both places, such as Rename WINTOOL to
CONFIG_CYGWIN_WINTOOL, etc.
First, I am going to send a PR to fix the ReleaseNotes in the repo.
Second, we need a new Documentation page, "Migrating From Older
NuttX." In this documentation, every compatibility change should be
documented, going from the present to at least as far back as NuttX
7.31. We can get all of these from the ReleaseNotes, but they should
be consolidated somewhere, so that someone like Sebastien who wants to
upgrade from version X to version Y can just go step by step and make
the necessary changes.
[1] https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns
[2] https://github.com/apache/incubator-nuttx/blob/master/ReleaseNotes
[3] http://nuttx.apache.org/releases/9.1.0/
Nathan
Re: [Discuss] Migrate the build system to CMake
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
Le 10/06/2021 à 02:00, Matias N. a écrit :
> 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.
I have no doubt that the new build system will work better.
I understand that it builds faster than the existing and requires less
kludges, and permits out of tree builds.
But it's a fundamental change about how to approach the NuttX OS globally.
The track record of this OS in terms of user documentation is not very
good, to be honest, it requires a lot of time to dig in various source
files and different web sites to understand how to do something.
This is not only my experience, it's the feeling of all of the ~10
persons I have tried to introduce to Nuttx: This OS is hard, it does not
guide beginners and it's hard to do "WHAT I WANT" (which is usually not
configuring nsh on a stm32f4discovery, but hands-on use case on custom
hardware with custom apps).
With that in mind, I am very worried of a supplemental dispersion of
useful documentation.
At what release/commit does the build system becomes cmake? before that,
please refer to the make build system documentation. chances are that
this doc quickly becomes 404, leaving all users of all versions in the
dark. for commits after that, please refer to this other documentation
on some personal blog, but only for release a.b.c later than this date.
I dont think cmake is technically wrong, but from a USER POINT OF VIEW,
it will become a nightmare and will drive new contributors away, because
of documentation problems.
Not to mention old users who spend weeks just to migrate a few boards
from an old to a new nuttx, just because a makefile and a critical
variable were renamed but no migration documentation exists. Add more
changes, and a project may become unusable in the current state of the
project.
So please. Keep NuttX interfaces STABLE for users that need it. It's not
a beta project anymore, it's "mature" as you advertise it, which means
it has some real industrial users that matter more than abstract
technical beauty. EXTRADEFINES now also need to include flags. hah, not
cool. I should rename that to EXTRAFLAGS, thats more cute. But how many
users will suffer from this apparently benign change? These questions
NEED to be asked by developers and contributors and reviewers.
When you make a change, please ask yourselves: how many unknown users
will I f*k up with that?
As a famous quote more or less goes, because it can be done does not
mean it should be done.
And having a generator that derives cmake files from current makefiles
feels a bit like xkcd #927
Sebastien
RE: [Discuss] Migrate the build system to CMake
Posted by David Sidrane <Da...@nscdg.com>.
First, I would like to apologies to Matias for not being able to contribute
to the effort. We are working on the PX4 release, and a nuttx upgrade and I
just do not have the time to spare.
Ironically time is one of the things this discussion is all about. PR with
the current build system and CI take hours to complete.
Yes hours!
This may a not be an issue for the causal Nuttx contributor. For
maintainers it is a waste of time and money from their companies or
sponsors. It slows development progress down to a crawl.
This is one of the key reasons why we need Cmake, Nijabuild, and ccache
(and persistence).
I am reminded by the 'if it ain't broke..." statement of the proud
carpenter holding his hand saw, in hand, watching the guy cutting plywood
sheeting with a Skill Saw. Saying if it ain't broke....
That is the level of improvement that we are talking about. Yes but now you
need power on the job site…. Yes we have to overcome the barriers…
There are a lot of changes happening in NuttX. The immediate value versus
the level of effort to upgrade is difficult to see sometimes. For instance,
in building PX4 with master I have a PR with 666 some odd files changes
tracking the inttypes change and header file inclusion changes. While
typing PRI... thousands of times it is hard to remember that catching the
cause of a crash in the compiler, at build time is far superior to hours
spent in the debugger. The include file changes add proper partitioning
this is a code quality issue.
Sometimes it seems like syntactical sugar or gratuitous renaming changes
are just dumb. They are not. What is dumb is not sharing the sed script or
a text file with the key was/is changes as part of the release. That is on
us. Hats off to AlexanderVasiljev for his comments in [1]. We need to do
this more! No Really we do. Sharing the reasons for the change and how to
apply it to a derivative of NuttX will make NuttX more successful.
Cmake is not in that class of gratuitous changes. The advantage of 22
second out of tree NuttX build will be an obvious. Yes it is a new tool,
yes there is a learning curve, yes I hate cmake some times.
The level of effort for adoption is very high for NuttX. Getting to a
successful build is the first roadblock. Expecting contributors to find and
use buried tooling as opposed to top level commands just digs the hole
deeper.
Is anyone getting tiered of telling contributors "just run
./tools/checkpatch.sh -g HEAD~...HEAD" yet?
If the readme said:
Installing the Tools
Run tools/nuttxtools_install.sh
Building the code
make board-config
make board-config menuconfig|newconfig|saveconfig
Check formatting
make format
Getting to a successful build would be simple.
Cmake will help with this goal on all OS platforms. We just need to invest
in supporting Cmake. Rebasing it constantly is not an option it will
eventually need to be on master. We can keep make and cmake side by side if
we can find value in it.
One other thing I would like to say is PX4 went from make to Cmake years
ago now. It promoted adoption. I would never go back. Even hating cmake,
sometimes the benefits far out way the hassles.
From that experience I can say it is important to do it right (refractor
with good design reviews of the user experience) and document it well. But
all the user has to type is `make board-config`
Regards,
David
[1] https://github.com/apache/incubator-nuttx/pull/3836#issue-660639554
-----Original Message-----
From: Matias N. [mailto:matias@imap.cc]
Sent: Wednesday, June 09, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: [Discuss] Migrate the build system to CMake
Hi,
I'll answer a few question that came up several times about build systems
co-existing. My previous answer was about co-existing them as a way to
satisfy
both set of users, which I don't think is the right approach. However, as a
transition
approach it does makes sense to me.
This is technically feasible however it will require adapting the Make
based system
as there were some changes needed to be made to Kconfig files, specifically
this one:
https://github.com/apache/incubator-nuttx/pull/3704/files?file-filters%5B%5D=.dat&file-filters%5B%5D=.pl&file-filters%5B%5D=.sh&file-filters%5B%5D=No+extension#diff-7c9693e9c5e61a1d80e09769377d47bb415ec39ca5aeaa85d13581b0105d6359
The main point is that CMake handles all steps related to build
configuration (e.g. build flags based on
optimization level) and platform detection. On master this is done via
Kconfig (with
settings which are stored in board defconfigs). One of these changes done
to Kconfig
is to pass the host-related variables as environment vars to Kconfig (so
that it still
possible to condition options based on platform).
So, co-existing the build systems would require dealing with this, which
I'm not sure
how easy would be.
With regards to comments about others requiring some hands-on time to become
familiar with the system and try it for themselves: I agree with this point
and was one
of the reasons I actually started the migration. As I mentioned several
weeks ago,
the cmake branch can already be tested on the currently supported boards by
everyone
wishing to do so, but I don't think anyone really tried it as my offers
about
assistance in this were unanswered.
Technical aspects aside: I do not wish to antagonize others not liking the
change.
I think I outlined the reasons I believe it is a positive change (and
others did so as well)
so now it is up to the community to decide what direction they wish to
follow.
In any case, if there's enough push forward, I would strongly recommend
that this is
explicitly decided via a vote (or any other mechanism considered
appropriate) with
a roadmap and organization, so that it becomes a goal for the NuttX project
and not
of just a subset of its community. I think this relates to making decisions
about the
project roadmap, which at some point needs to be done in an "official
capacity".
Best,
Matias
PS: the PR can always be reopened and the code lives on a branch on my fork.
The branch on the repo does not yet contain anything, it simply acts as a
stable base
for the PR (and, of course, protects master from the merge, if it ever
happens).
On Wed, Jun 9, 2021, at 18:32, Nathan Hartman wrote:
> On Wed, Jun 9, 2021 at 3:07 PM Matias N. <matias@imap.cc <mailto:
matias%40imap.cc>> wrote:
> > I will leave up to PPMC to decide whether a call to a vote is
necessary/useful, but
> > to me the community response is now quite clear. Also, voting based on
majority
> > would not really consider that such a change actually requires
significant
> > backing from the comunity. I will therefore will not continue working
on this
> > (you can delete the branch).
>
> Please don't delete the branch.
>
> Although switching build systems is a scary thought, I think we should
> be open-minded about trying it. As I suggested before, and I think two
> other people said something similar, perhaps the CMake can coexist
> with the current Make build system somehow, even if it's labeled
> "Experimental." Yes I know that creates more maintenance burden, and a
> few people said it doesn't make sense to manage multiple build
> systems, but other people pointed out that all downstream users will
> need to rework their out-of-tree boards/frameworks/etc to adopt CMake.
> That might make some people upset; but it will probably make some
> people happy too, and we (or at least I) don't know which group is
> bigger. In either case, with such a big change, I really think it
> can't just happen in one atomic commit. For example, think of the
> Python 2 -> Python 3 transition. That has been going on for how many
> years now?! This proposed change won't take that long to transition,
> but it will still need time. If we could have both build systems for a
> while, it would allow people to test the waters with CMake but fall
> back on Make if they hit problems and need to get their work done; it
> will likely get a lot of feedback and fixes; and eventually depending
> on how good it gets, we can deprecate Make and take CMake out of
> "experimental" status. This is a disadvantage for maintenance, but it
> will give downstream a transition period that will be needed for this
> kind of change.
>
> In any event, whatever you do, please DON'T delete that branch!
>
> It would be better to find a way to merge it back to master without
> destroying the existing Make system.
>
> That's just my two [insert 2/100 of your favorite currency here].
>
> Nathan
>
Re: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
Hi,
I'll answer a few question that came up several times about build systems
co-existing. My previous answer was about co-existing them as a way to satisfy
both set of users, which I don't think is the right approach. However, as a transition
approach it does makes sense to me.
This is technically feasible however it will require adapting the Make based system
as there were some changes needed to be made to Kconfig files, specifically this one:
https://github.com/apache/incubator-nuttx/pull/3704/files?file-filters%5B%5D=.dat&file-filters%5B%5D=.pl&file-filters%5B%5D=.sh&file-filters%5B%5D=No+extension#diff-7c9693e9c5e61a1d80e09769377d47bb415ec39ca5aeaa85d13581b0105d6359
The main point is that CMake handles all steps related to build configuration (e.g. build flags based on
optimization level) and platform detection. On master this is done via Kconfig (with
settings which are stored in board defconfigs). One of these changes done to Kconfig
is to pass the host-related variables as environment vars to Kconfig (so that it still
possible to condition options based on platform).
So, co-existing the build systems would require dealing with this, which I'm not sure
how easy would be.
With regards to comments about others requiring some hands-on time to become
familiar with the system and try it for themselves: I agree with this point and was one
of the reasons I actually started the migration. As I mentioned several weeks ago,
the cmake branch can already be tested on the currently supported boards by everyone
wishing to do so, but I don't think anyone really tried it as my offers about
assistance in this were unanswered.
Technical aspects aside: I do not wish to antagonize others not liking the change.
I think I outlined the reasons I believe it is a positive change (and others did so as well)
so now it is up to the community to decide what direction they wish to follow.
In any case, if there's enough push forward, I would strongly recommend that this is
explicitly decided via a vote (or any other mechanism considered appropriate) with
a roadmap and organization, so that it becomes a goal for the NuttX project and not
of just a subset of its community. I think this relates to making decisions about the
project roadmap, which at some point needs to be done in an "official capacity".
Best,
Matias
PS: the PR can always be reopened and the code lives on a branch on my fork.
The branch on the repo does not yet contain anything, it simply acts as a stable base
for the PR (and, of course, protects master from the merge, if it ever happens).
On Wed, Jun 9, 2021, at 18:32, Nathan Hartman wrote:
> On Wed, Jun 9, 2021 at 3:07 PM Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
> > I will leave up to PPMC to decide whether a call to a vote is necessary/useful, but
> > to me the community response is now quite clear. Also, voting based on majority
> > would not really consider that such a change actually requires significant
> > backing from the comunity. I will therefore will not continue working on this
> > (you can delete the branch).
>
> Please don't delete the branch.
>
> Although switching build systems is a scary thought, I think we should
> be open-minded about trying it. As I suggested before, and I think two
> other people said something similar, perhaps the CMake can coexist
> with the current Make build system somehow, even if it's labeled
> "Experimental." Yes I know that creates more maintenance burden, and a
> few people said it doesn't make sense to manage multiple build
> systems, but other people pointed out that all downstream users will
> need to rework their out-of-tree boards/frameworks/etc to adopt CMake.
> That might make some people upset; but it will probably make some
> people happy too, and we (or at least I) don't know which group is
> bigger. In either case, with such a big change, I really think it
> can't just happen in one atomic commit. For example, think of the
> Python 2 -> Python 3 transition. That has been going on for how many
> years now?! This proposed change won't take that long to transition,
> but it will still need time. If we could have both build systems for a
> while, it would allow people to test the waters with CMake but fall
> back on Make if they hit problems and need to get their work done; it
> will likely get a lot of feedback and fixes; and eventually depending
> on how good it gets, we can deprecate Make and take CMake out of
> "experimental" status. This is a disadvantage for maintenance, but it
> will give downstream a transition period that will be needed for this
> kind of change.
>
> In any event, whatever you do, please DON'T delete that branch!
>
> It would be better to find a way to merge it back to master without
> destroying the existing Make system.
>
> That's just my two [insert 2/100 of your favorite currency here].
>
> Nathan
>
Re: [Discuss] Migrate the build system to CMake
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Jun 9, 2021 at 3:07 PM Matias N. <ma...@imap.cc> wrote:
> I will leave up to PPMC to decide whether a call to a vote is necessary/useful, but
> to me the community response is now quite clear. Also, voting based on majority
> would not really consider that such a change actually requires significant
> backing from the comunity. I will therefore will not continue working on this
> (you can delete the branch).
Please don't delete the branch.
Although switching build systems is a scary thought, I think we should
be open-minded about trying it. As I suggested before, and I think two
other people said something similar, perhaps the CMake can coexist
with the current Make build system somehow, even if it's labeled
"Experimental." Yes I know that creates more maintenance burden, and a
few people said it doesn't make sense to manage multiple build
systems, but other people pointed out that all downstream users will
need to rework their out-of-tree boards/frameworks/etc to adopt CMake.
That might make some people upset; but it will probably make some
people happy too, and we (or at least I) don't know which group is
bigger. In either case, with such a big change, I really think it
can't just happen in one atomic commit. For example, think of the
Python 2 -> Python 3 transition. That has been going on for how many
years now?! This proposed change won't take that long to transition,
but it will still need time. If we could have both build systems for a
while, it would allow people to test the waters with CMake but fall
back on Make if they hit problems and need to get their work done; it
will likely get a lot of feedback and fixes; and eventually depending
on how good it gets, we can deprecate Make and take CMake out of
"experimental" status. This is a disadvantage for maintenance, but it
will give downstream a transition period that will be needed for this
kind of change.
In any event, whatever you do, please DON'T delete that branch!
It would be better to find a way to merge it back to master without
destroying the existing Make system.
That's just my two [insert 2/100 of your favorite currency here].
Nathan
Re: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
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 <
> alexvasiljev@gmail.com <mailto:alexvasiljev%40gmail.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 <pettitkd@gmail.com <mailto:pettitkd%40gmail.com>>:
> >
> > > My opinion:
> > >
> > > CMake is horrible. Don't do it. It's hard to use for beginners, and
> > > hard to use for anyone who isn't just a strong advocate for it.
> > >
> > > Just my opionion.
> > > Ken
> > >
> > >
> > > On 6/9/21 6:46 AM, Gregory Nutt wrote:
> > > > I think that there a lot of people like myself who are opposed to the
> > > > CMake change but are remain silent to let the community make the
> > > > decision. I suspect that the advocates of CMake are having a larger
> > > > voice in the decision.
> > > >
> > > > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
> > > >> Hello,
> > > >>
> > > >> I believe in a stong principle, applied successfully numerous time in
> > > >> my embedded development company:
> > > >>
> > > >>
> > > >> It it's not broken, dont fix it.
> > > >>
> > > >>
> > > >> That applies precisely to this change.
> > > >>
> > > >> The build system we have have the following characteristics
> > > >>
> > > >> -it works for its intended purposes
> > > >>
> > > >> -it is pretty complex
> > > >>
> > > >> -ALL USERS have become used to it
> > > >>
> > > >>
> > > >> Changing it
> > > >>
> > > >> - will bring a lot of new bugs
> > > >>
> > > >> - along with the annoying feeling that these bugs were not necessary
> > > >> in the first place
> > > >>
> > > >> - No one will understand the build system anymore
> > > >>
> > > >> - since makefiles are now generated, we rely on yet another external
> > > >> tool with bugs in itself, and its idiosyncrasies and workarounds.
> > > >>
> > > >>
> > > >> Moreover:
> > > >>
> > > >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
> > > >> the nuttx documentation will become fully obsolete overnight.
> > > >>
> > > >>
> > > >> Gratuitous changes are a hell, they destroy efficiency.
> > > >>
> > > >> They tend to appear more frequently in open source projects, because
> > > >> anyone can bring it change without a single damn given to customer
> > > >> since the code has no warranty of fitness of etc etc open source
> > > >> legalese.
> > > >>
> > > >>
> > > >> If it was me, I would not do this change. If I had to take a decision
> > > >> about something similar in my company, it would be a strong no.
> > > >>
> > > >>
> > > >> Sebastien
> > > >>
> > > >>
> > > >> Le 09/06/2021 à 14:57, Matias N. a écrit :
> > > >>> Hi everyone,
> > > >>>
> > > >>> this thread has received little engagement from the community
> > > >>> in general, for a change with such impact on daily use of NuttX
> > > >>> for everyone.
> > > >>>
> > > >>> While there was positive feedback on GH and a few people have
> > > >>> expressed more interest, not much has really happened. Meanwhile,
> > > >>> the backlog of changes that would need to be backported continues
> > > >>> to increase.
> > > >>>
> > > >>> At the same time, I see many PRs addressing subtle issues with
> > > >>> current build system, which are mostly already solved with the
> > > >>> migration
> > > >>> to CMake. So there's continued effort in maintaining the current
> > system
> > > >>> which could be in part dedicated to the migration to a better system.
> > > >>>
> > > >>> I have offered technical guidance on testing and extending to other
> > > >>> platforms and also to add base support for other arch's so that the
> > > >>> focus
> > > >>> can be put mostly at the board level and on test and validation on
> > > >>> different
> > > >>> platforms and target hardware. However, after having worked on this
> > > >>> for more than a month I feel this is not really picking up the
> > > >>> interest it
> > > >>> requires for proper adoption by the community.
> > > >>>
> > > >>> Maybe the proper approach would be to call on a vote (*)
> > > >>> for this feature to have explicit support from the community and
> > > >>> ensure involvement from others than me to move forward.
> > > >>> Otherwise, or if the vote does not pass, I will not be pushing
> > > >>> forward with this.
> > > >>>
> > > >>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally
> > > >>> call on
> > > >>> a vote and what the exact procedure is, but maybe other PPMC member
> > > >>> can do so.
> > > >>>
> > > >>> Best,
> > > >>> Matias
> > > >>>
> > > >>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
> > > >>>> I am interested and I'll try to help with boards I can test. It
> > > >>>> will take a
> > > >>>> few days to get around to it because this has been a busy month,
> > > >>>> but I'm
> > > >>>> catching up.
> > > >>>>
> > > >>>> Cheers
> > > >>>> Nathan
> > > >>>>
> > > >>>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis
> > > >>>> <acassis@gmail.com <mailto:acassis%40gmail.com> <mailto:acassis%40gmail.com>>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> I think we can divide the effort to port all the boards to the new
> > > >>>>> CMake.
> > > >>>>>
> > > >>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> > > >>>>>
> > > >>>>> Let see if we get more people involved in this effort.
> > > >>>>>
> > > >>>>> BR,
> > > >>>>>
> > > >>>>> Alan
> > > >>>>>
> > > >>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc> <mailto:matias%40imap.cc>>
> > > >>>>> wrote:
> > > >>>>>> Hi,
> > > >>>>>> just wanted to add that until this is ready, the gap between
> > > >>>>>> master and
> > > >>>>> the
> > > >>>>>> branch
> > > >>>>>> widens with every merged PR and this increases the backporting
> > > >>>>>> effort.
> > > >>>>>> I'm willing to do most of the remaining work but as I mentioned I
> > > >>>>>> cannot
> > > >>>>>> possibly test everything so
> > > >>>>>> help is needed.
> > > >>>>>> I'd really like your feedback on this before I continue and
> > > >>>>>> ensure the
> > > >>>>>> effort will not go to waste.
> > > >>>>>>
> > > >>>>>> Best,
> > > >>>>>> Matias
> > > >>>>>>
> > > >>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> > > >>>>>>> Hi,
> > > >>>>>>> for anyone not following the relevant PR, please have a look at
> > the
> > > >>>>>>> current state here:
> > > >>>>>>>
> > > >>>>>>> https://github.com/apache/incubator-nuttx/pull/3704
> > > >>>>>>>
> > > >>>>>>> This is now at a point where it can be tested by others. It
> > > >>>>>>> would be
> > > >>>>> very
> > > >>>>>>> good to get some
> > > >>>>>>> help testing what I got so far (sim and stm32f4discovery, both
> > > >>>>>>> on Linux
> > > >>>>>>> and mac), by running
> > > >>>>>>> examples and test. There are some brief instructions at the end
> > > >>>>>>> of the
> > > >>>>> PR
> > > >>>>>>> description for building.
> > > >>>>>>>
> > > >>>>>>> Other than that, I can continue porting other arch's and boards
> > > >>>>>>> with the
> > > >>>>>>> help of CI but it would be
> > > >>>>>>> best if others with more boards could help testing (and ideally
> > > >>>>>>> with
> > > >>>>> some
> > > >>>>>>> PRs, as the hard part
> > > >>>>>>> is mostly done) those as well.
> > > >>>>>>>
> > > >>>>>>> Also, note that this is a PR against a branch so we could
> > > >>>>>>> eventually
> > > >>>>> merge
> > > >>>>>>> it before adding support
> > > >>>>>>> for other arch/boards. And finally, I will provide documentation
> > > >>>>>>> to the
> > > >>>>>>> new build system in a separate
> > > >>>>>>> PR at some point, which I hope will ease the transition and help
> > > >>>>>>> reviewing.
> > > >>>>>>>
> > > >>>>>>> Best,
> > > >>>>>>> Matias
> > > >>>>>>>
> > > >>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> > > >>>>>>>> A new issue is opened recently to address this topic:
> > > >>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
> > > >>>>>>>> This proposal has the depth of the impact in our daily working,
> > > >>>>>>>> so it's
> > > >>>>>>>> very important to get the feedback from the community before
> > > >>>>>>>> the real
> > > >>>>>>>> action is taken.
> > > >>>>>>>> If you have any concern or suggestion, please reply to this
> > email.
> > > >>>>>>>>
> > > >>>>>>>> Thanks
> > > >>>>>>>> Xiang
> > > >>>>>>>>
> > > >
> > >
> > >
> >
>
Re: [Discuss] Migrate the build system to CMake
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
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 <
alexvasiljev@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 <pe...@gmail.com>:
>
> > My opinion:
> >
> > CMake is horrible. Don't do it. It's hard to use for beginners, and
> > hard to use for anyone who isn't just a strong advocate for it.
> >
> > Just my opionion.
> > Ken
> >
> >
> > On 6/9/21 6:46 AM, Gregory Nutt wrote:
> > > I think that there a lot of people like myself who are opposed to the
> > > CMake change but are remain silent to let the community make the
> > > decision. I suspect that the advocates of CMake are having a larger
> > > voice in the decision.
> > >
> > > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
> > >> Hello,
> > >>
> > >> I believe in a stong principle, applied successfully numerous time in
> > >> my embedded development company:
> > >>
> > >>
> > >> It it's not broken, dont fix it.
> > >>
> > >>
> > >> That applies precisely to this change.
> > >>
> > >> The build system we have have the following characteristics
> > >>
> > >> -it works for its intended purposes
> > >>
> > >> -it is pretty complex
> > >>
> > >> -ALL USERS have become used to it
> > >>
> > >>
> > >> Changing it
> > >>
> > >> - will bring a lot of new bugs
> > >>
> > >> - along with the annoying feeling that these bugs were not necessary
> > >> in the first place
> > >>
> > >> - No one will understand the build system anymore
> > >>
> > >> - since makefiles are now generated, we rely on yet another external
> > >> tool with bugs in itself, and its idiosyncrasies and workarounds.
> > >>
> > >>
> > >> Moreover:
> > >>
> > >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
> > >> the nuttx documentation will become fully obsolete overnight.
> > >>
> > >>
> > >> Gratuitous changes are a hell, they destroy efficiency.
> > >>
> > >> They tend to appear more frequently in open source projects, because
> > >> anyone can bring it change without a single damn given to customer
> > >> since the code has no warranty of fitness of etc etc open source
> > >> legalese.
> > >>
> > >>
> > >> If it was me, I would not do this change. If I had to take a decision
> > >> about something similar in my company, it would be a strong no.
> > >>
> > >>
> > >> Sebastien
> > >>
> > >>
> > >> Le 09/06/2021 à 14:57, Matias N. a écrit :
> > >>> Hi everyone,
> > >>>
> > >>> this thread has received little engagement from the community
> > >>> in general, for a change with such impact on daily use of NuttX
> > >>> for everyone.
> > >>>
> > >>> While there was positive feedback on GH and a few people have
> > >>> expressed more interest, not much has really happened. Meanwhile,
> > >>> the backlog of changes that would need to be backported continues
> > >>> to increase.
> > >>>
> > >>> At the same time, I see many PRs addressing subtle issues with
> > >>> current build system, which are mostly already solved with the
> > >>> migration
> > >>> to CMake. So there's continued effort in maintaining the current
> system
> > >>> which could be in part dedicated to the migration to a better system.
> > >>>
> > >>> I have offered technical guidance on testing and extending to other
> > >>> platforms and also to add base support for other arch's so that the
> > >>> focus
> > >>> can be put mostly at the board level and on test and validation on
> > >>> different
> > >>> platforms and target hardware. However, after having worked on this
> > >>> for more than a month I feel this is not really picking up the
> > >>> interest it
> > >>> requires for proper adoption by the community.
> > >>>
> > >>> Maybe the proper approach would be to call on a vote (*)
> > >>> for this feature to have explicit support from the community and
> > >>> ensure involvement from others than me to move forward.
> > >>> Otherwise, or if the vote does not pass, I will not be pushing
> > >>> forward with this.
> > >>>
> > >>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally
> > >>> call on
> > >>> a vote and what the exact procedure is, but maybe other PPMC member
> > >>> can do so.
> > >>>
> > >>> Best,
> > >>> Matias
> > >>>
> > >>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
> > >>>> I am interested and I'll try to help with boards I can test. It
> > >>>> will take a
> > >>>> few days to get around to it because this has been a busy month,
> > >>>> but I'm
> > >>>> catching up.
> > >>>>
> > >>>> Cheers
> > >>>> Nathan
> > >>>>
> > >>>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis
> > >>>> <acassis@gmail.com <mailto:acassis%40gmail.com>>
> > >>>> wrote:
> > >>>>
> > >>>>> I think we can divide the effort to port all the boards to the new
> > >>>>> CMake.
> > >>>>>
> > >>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> > >>>>>
> > >>>>> Let see if we get more people involved in this effort.
> > >>>>>
> > >>>>> BR,
> > >>>>>
> > >>>>> Alan
> > >>>>>
> > >>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>>
> > >>>>> wrote:
> > >>>>>> Hi,
> > >>>>>> just wanted to add that until this is ready, the gap between
> > >>>>>> master and
> > >>>>> the
> > >>>>>> branch
> > >>>>>> widens with every merged PR and this increases the backporting
> > >>>>>> effort.
> > >>>>>> I'm willing to do most of the remaining work but as I mentioned I
> > >>>>>> cannot
> > >>>>>> possibly test everything so
> > >>>>>> help is needed.
> > >>>>>> I'd really like your feedback on this before I continue and
> > >>>>>> ensure the
> > >>>>>> effort will not go to waste.
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Matias
> > >>>>>>
> > >>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> > >>>>>>> Hi,
> > >>>>>>> for anyone not following the relevant PR, please have a look at
> the
> > >>>>>>> current state here:
> > >>>>>>>
> > >>>>>>> https://github.com/apache/incubator-nuttx/pull/3704
> > >>>>>>>
> > >>>>>>> This is now at a point where it can be tested by others. It
> > >>>>>>> would be
> > >>>>> very
> > >>>>>>> good to get some
> > >>>>>>> help testing what I got so far (sim and stm32f4discovery, both
> > >>>>>>> on Linux
> > >>>>>>> and mac), by running
> > >>>>>>> examples and test. There are some brief instructions at the end
> > >>>>>>> of the
> > >>>>> PR
> > >>>>>>> description for building.
> > >>>>>>>
> > >>>>>>> Other than that, I can continue porting other arch's and boards
> > >>>>>>> with the
> > >>>>>>> help of CI but it would be
> > >>>>>>> best if others with more boards could help testing (and ideally
> > >>>>>>> with
> > >>>>> some
> > >>>>>>> PRs, as the hard part
> > >>>>>>> is mostly done) those as well.
> > >>>>>>>
> > >>>>>>> Also, note that this is a PR against a branch so we could
> > >>>>>>> eventually
> > >>>>> merge
> > >>>>>>> it before adding support
> > >>>>>>> for other arch/boards. And finally, I will provide documentation
> > >>>>>>> to the
> > >>>>>>> new build system in a separate
> > >>>>>>> PR at some point, which I hope will ease the transition and help
> > >>>>>>> reviewing.
> > >>>>>>>
> > >>>>>>> Best,
> > >>>>>>> Matias
> > >>>>>>>
> > >>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> > >>>>>>>> A new issue is opened recently to address this topic:
> > >>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
> > >>>>>>>> This proposal has the depth of the impact in our daily working,
> > >>>>>>>> so it's
> > >>>>>>>> very important to get the feedback from the community before
> > >>>>>>>> the real
> > >>>>>>>> action is taken.
> > >>>>>>>> If you have any concern or suggestion, please reply to this
> email.
> > >>>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>> Xiang
> > >>>>>>>>
> > >
> >
> >
>
Re: [Discuss] Migrate the build system to CMake
Posted by Alexander Vasiliev <al...@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 <pe...@gmail.com>:
> My opinion:
>
> CMake is horrible. Don't do it. It's hard to use for beginners, and
> hard to use for anyone who isn't just a strong advocate for it.
>
> Just my opionion.
> Ken
>
>
> On 6/9/21 6:46 AM, Gregory Nutt wrote:
> > I think that there a lot of people like myself who are opposed to the
> > CMake change but are remain silent to let the community make the
> > decision. I suspect that the advocates of CMake are having a larger
> > voice in the decision.
> >
> > On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
> >> Hello,
> >>
> >> I believe in a stong principle, applied successfully numerous time in
> >> my embedded development company:
> >>
> >>
> >> It it's not broken, dont fix it.
> >>
> >>
> >> That applies precisely to this change.
> >>
> >> The build system we have have the following characteristics
> >>
> >> -it works for its intended purposes
> >>
> >> -it is pretty complex
> >>
> >> -ALL USERS have become used to it
> >>
> >>
> >> Changing it
> >>
> >> - will bring a lot of new bugs
> >>
> >> - along with the annoying feeling that these bugs were not necessary
> >> in the first place
> >>
> >> - No one will understand the build system anymore
> >>
> >> - since makefiles are now generated, we rely on yet another external
> >> tool with bugs in itself, and its idiosyncrasies and workarounds.
> >>
> >>
> >> Moreover:
> >>
> >> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
> >> the nuttx documentation will become fully obsolete overnight.
> >>
> >>
> >> Gratuitous changes are a hell, they destroy efficiency.
> >>
> >> They tend to appear more frequently in open source projects, because
> >> anyone can bring it change without a single damn given to customer
> >> since the code has no warranty of fitness of etc etc open source
> >> legalese.
> >>
> >>
> >> If it was me, I would not do this change. If I had to take a decision
> >> about something similar in my company, it would be a strong no.
> >>
> >>
> >> Sebastien
> >>
> >>
> >> Le 09/06/2021 à 14:57, Matias N. a écrit :
> >>> Hi everyone,
> >>>
> >>> this thread has received little engagement from the community
> >>> in general, for a change with such impact on daily use of NuttX
> >>> for everyone.
> >>>
> >>> While there was positive feedback on GH and a few people have
> >>> expressed more interest, not much has really happened. Meanwhile,
> >>> the backlog of changes that would need to be backported continues
> >>> to increase.
> >>>
> >>> At the same time, I see many PRs addressing subtle issues with
> >>> current build system, which are mostly already solved with the
> >>> migration
> >>> to CMake. So there's continued effort in maintaining the current system
> >>> which could be in part dedicated to the migration to a better system.
> >>>
> >>> I have offered technical guidance on testing and extending to other
> >>> platforms and also to add base support for other arch's so that the
> >>> focus
> >>> can be put mostly at the board level and on test and validation on
> >>> different
> >>> platforms and target hardware. However, after having worked on this
> >>> for more than a month I feel this is not really picking up the
> >>> interest it
> >>> requires for proper adoption by the community.
> >>>
> >>> Maybe the proper approach would be to call on a vote (*)
> >>> for this feature to have explicit support from the community and
> >>> ensure involvement from others than me to move forward.
> >>> Otherwise, or if the vote does not pass, I will not be pushing
> >>> forward with this.
> >>>
> >>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally
> >>> call on
> >>> a vote and what the exact procedure is, but maybe other PPMC member
> >>> can do so.
> >>>
> >>> Best,
> >>> Matias
> >>>
> >>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
> >>>> I am interested and I'll try to help with boards I can test. It
> >>>> will take a
> >>>> few days to get around to it because this has been a busy month,
> >>>> but I'm
> >>>> catching up.
> >>>>
> >>>> Cheers
> >>>> Nathan
> >>>>
> >>>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis
> >>>> <acassis@gmail.com <mailto:acassis%40gmail.com>>
> >>>> wrote:
> >>>>
> >>>>> I think we can divide the effort to port all the boards to the new
> >>>>> CMake.
> >>>>>
> >>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> >>>>>
> >>>>> Let see if we get more people involved in this effort.
> >>>>>
> >>>>> BR,
> >>>>>
> >>>>> Alan
> >>>>>
> >>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>>
> >>>>> wrote:
> >>>>>> Hi,
> >>>>>> just wanted to add that until this is ready, the gap between
> >>>>>> master and
> >>>>> the
> >>>>>> branch
> >>>>>> widens with every merged PR and this increases the backporting
> >>>>>> effort.
> >>>>>> I'm willing to do most of the remaining work but as I mentioned I
> >>>>>> cannot
> >>>>>> possibly test everything so
> >>>>>> help is needed.
> >>>>>> I'd really like your feedback on this before I continue and
> >>>>>> ensure the
> >>>>>> effort will not go to waste.
> >>>>>>
> >>>>>> Best,
> >>>>>> Matias
> >>>>>>
> >>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> >>>>>>> Hi,
> >>>>>>> for anyone not following the relevant PR, please have a look at the
> >>>>>>> current state here:
> >>>>>>>
> >>>>>>> https://github.com/apache/incubator-nuttx/pull/3704
> >>>>>>>
> >>>>>>> This is now at a point where it can be tested by others. It
> >>>>>>> would be
> >>>>> very
> >>>>>>> good to get some
> >>>>>>> help testing what I got so far (sim and stm32f4discovery, both
> >>>>>>> on Linux
> >>>>>>> and mac), by running
> >>>>>>> examples and test. There are some brief instructions at the end
> >>>>>>> of the
> >>>>> PR
> >>>>>>> description for building.
> >>>>>>>
> >>>>>>> Other than that, I can continue porting other arch's and boards
> >>>>>>> with the
> >>>>>>> help of CI but it would be
> >>>>>>> best if others with more boards could help testing (and ideally
> >>>>>>> with
> >>>>> some
> >>>>>>> PRs, as the hard part
> >>>>>>> is mostly done) those as well.
> >>>>>>>
> >>>>>>> Also, note that this is a PR against a branch so we could
> >>>>>>> eventually
> >>>>> merge
> >>>>>>> it before adding support
> >>>>>>> for other arch/boards. And finally, I will provide documentation
> >>>>>>> to the
> >>>>>>> new build system in a separate
> >>>>>>> PR at some point, which I hope will ease the transition and help
> >>>>>>> reviewing.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Matias
> >>>>>>>
> >>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> >>>>>>>> A new issue is opened recently to address this topic:
> >>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
> >>>>>>>> This proposal has the depth of the impact in our daily working,
> >>>>>>>> so it's
> >>>>>>>> very important to get the feedback from the community before
> >>>>>>>> the real
> >>>>>>>> action is taken.
> >>>>>>>> If you have any concern or suggestion, please reply to this email.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Xiang
> >>>>>>>>
> >
>
>
Re: [Discuss] Migrate the build system to CMake
Posted by Ken Pettit <pe...@gmail.com>.
My opinion:
CMake is horrible. Don't do it. It's hard to use for beginners, and
hard to use for anyone who isn't just a strong advocate for it.
Just my opionion.
Ken
On 6/9/21 6:46 AM, Gregory Nutt wrote:
> I think that there a lot of people like myself who are opposed to the
> CMake change but are remain silent to let the community make the
> decision. I suspect that the advocates of CMake are having a larger
> voice in the decision.
>
> On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:
>> Hello,
>>
>> I believe in a stong principle, applied successfully numerous time in
>> my embedded development company:
>>
>>
>> It it's not broken, dont fix it.
>>
>>
>> That applies precisely to this change.
>>
>> The build system we have have the following characteristics
>>
>> -it works for its intended purposes
>>
>> -it is pretty complex
>>
>> -ALL USERS have become used to it
>>
>>
>> Changing it
>>
>> - will bring a lot of new bugs
>>
>> - along with the annoying feeling that these bugs were not necessary
>> in the first place
>>
>> - No one will understand the build system anymore
>>
>> - since makefiles are now generated, we rely on yet another external
>> tool with bugs in itself, and its idiosyncrasies and workarounds.
>>
>>
>> Moreover:
>>
>> -the doc about nuttx is not hosted by the nuttx project, so 99 % of
>> the nuttx documentation will become fully obsolete overnight.
>>
>>
>> Gratuitous changes are a hell, they destroy efficiency.
>>
>> They tend to appear more frequently in open source projects, because
>> anyone can bring it change without a single damn given to customer
>> since the code has no warranty of fitness of etc etc open source
>> legalese.
>>
>>
>> If it was me, I would not do this change. If I had to take a decision
>> about something similar in my company, it would be a strong no.
>>
>>
>> Sebastien
>>
>>
>> Le 09/06/2021 à 14:57, Matias N. a écrit :
>>> Hi everyone,
>>>
>>> this thread has received little engagement from the community
>>> in general, for a change with such impact on daily use of NuttX
>>> for everyone.
>>>
>>> While there was positive feedback on GH and a few people have
>>> expressed more interest, not much has really happened. Meanwhile,
>>> the backlog of changes that would need to be backported continues
>>> to increase.
>>>
>>> At the same time, I see many PRs addressing subtle issues with
>>> current build system, which are mostly already solved with the
>>> migration
>>> to CMake. So there's continued effort in maintaining the current system
>>> which could be in part dedicated to the migration to a better system.
>>>
>>> I have offered technical guidance on testing and extending to other
>>> platforms and also to add base support for other arch's so that the
>>> focus
>>> can be put mostly at the board level and on test and validation on
>>> different
>>> platforms and target hardware. However, after having worked on this
>>> for more than a month I feel this is not really picking up the
>>> interest it
>>> requires for proper adoption by the community.
>>>
>>> Maybe the proper approach would be to call on a vote (*)
>>> for this feature to have explicit support from the community and
>>> ensure involvement from others than me to move forward.
>>> Otherwise, or if the vote does not pass, I will not be pushing
>>> forward with this.
>>>
>>> (*) As a commiter (non-PPMC member), I'm not sure if I can formally
>>> call on
>>> a vote and what the exact procedure is, but maybe other PPMC member
>>> can do so.
>>>
>>> Best,
>>> Matias
>>>
>>> On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
>>>> I am interested and I'll try to help with boards I can test. It
>>>> will take a
>>>> few days to get around to it because this has been a busy month,
>>>> but I'm
>>>> catching up.
>>>>
>>>> Cheers
>>>> Nathan
>>>>
>>>> On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis
>>>> <acassis@gmail.com <mailto:acassis%40gmail.com>>
>>>> wrote:
>>>>
>>>>> I think we can divide the effort to port all the boards to the new
>>>>> CMake.
>>>>>
>>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>>>
>>>>> Let see if we get more people involved in this effort.
>>>>>
>>>>> BR,
>>>>>
>>>>> Alan
>>>>>
>>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>>
>>>>> wrote:
>>>>>> Hi,
>>>>>> just wanted to add that until this is ready, the gap between
>>>>>> master and
>>>>> the
>>>>>> branch
>>>>>> widens with every merged PR and this increases the backporting
>>>>>> effort.
>>>>>> I'm willing to do most of the remaining work but as I mentioned I
>>>>>> cannot
>>>>>> possibly test everything so
>>>>>> help is needed.
>>>>>> I'd really like your feedback on this before I continue and
>>>>>> ensure the
>>>>>> effort will not go to waste.
>>>>>>
>>>>>> Best,
>>>>>> Matias
>>>>>>
>>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>>>>>>> Hi,
>>>>>>> for anyone not following the relevant PR, please have a look at the
>>>>>>> current state here:
>>>>>>>
>>>>>>> https://github.com/apache/incubator-nuttx/pull/3704
>>>>>>>
>>>>>>> This is now at a point where it can be tested by others. It
>>>>>>> would be
>>>>> very
>>>>>>> good to get some
>>>>>>> help testing what I got so far (sim and stm32f4discovery, both
>>>>>>> on Linux
>>>>>>> and mac), by running
>>>>>>> examples and test. There are some brief instructions at the end
>>>>>>> of the
>>>>> PR
>>>>>>> description for building.
>>>>>>>
>>>>>>> Other than that, I can continue porting other arch's and boards
>>>>>>> with the
>>>>>>> help of CI but it would be
>>>>>>> best if others with more boards could help testing (and ideally
>>>>>>> with
>>>>> some
>>>>>>> PRs, as the hard part
>>>>>>> is mostly done) those as well.
>>>>>>>
>>>>>>> Also, note that this is a PR against a branch so we could
>>>>>>> eventually
>>>>> merge
>>>>>>> it before adding support
>>>>>>> for other arch/boards. And finally, I will provide documentation
>>>>>>> to the
>>>>>>> new build system in a separate
>>>>>>> PR at some point, which I hope will ease the transition and help
>>>>>>> reviewing.
>>>>>>>
>>>>>>> Best,
>>>>>>> Matias
>>>>>>>
>>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>>>>>>>> A new issue is opened recently to address this topic:
>>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
>>>>>>>> This proposal has the depth of the impact in our daily working,
>>>>>>>> so it's
>>>>>>>> very important to get the feedback from the community before
>>>>>>>> the real
>>>>>>>> action is taken.
>>>>>>>> If you have any concern or suggestion, please reply to this email.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Xiang
>>>>>>>>
>
Re: [Discuss] Migrate the build system to CMake
Posted by Gregory Nutt <sp...@gmail.com>.
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
>>> <acassis@gmail.com <mailto:acassis%40gmail.com>>
>>> wrote:
>>>
>>>> I think we can divide the effort to port all the boards to the new
>>>> CMake.
>>>>
>>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>>
>>>> Let see if we get more people involved in this effort.
>>>>
>>>> BR,
>>>>
>>>> Alan
>>>>
>>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
>>>>> Hi,
>>>>> just wanted to add that until this is ready, the gap between
>>>>> master and
>>>> the
>>>>> branch
>>>>> widens with every merged PR and this increases the backporting
>>>>> effort.
>>>>> I'm willing to do most of the remaining work but as I mentioned I
>>>>> cannot
>>>>> possibly test everything so
>>>>> help is needed.
>>>>> I'd really like your feedback on this before I continue and ensure
>>>>> the
>>>>> effort will not go to waste.
>>>>>
>>>>> Best,
>>>>> Matias
>>>>>
>>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>>>>>> Hi,
>>>>>> for anyone not following the relevant PR, please have a look at the
>>>>>> current state here:
>>>>>>
>>>>>> https://github.com/apache/incubator-nuttx/pull/3704
>>>>>>
>>>>>> This is now at a point where it can be tested by others. It would be
>>>> very
>>>>>> good to get some
>>>>>> help testing what I got so far (sim and stm32f4discovery, both on
>>>>>> Linux
>>>>>> and mac), by running
>>>>>> examples and test. There are some brief instructions at the end
>>>>>> of the
>>>> PR
>>>>>> description for building.
>>>>>>
>>>>>> Other than that, I can continue porting other arch's and boards
>>>>>> with the
>>>>>> help of CI but it would be
>>>>>> best if others with more boards could help testing (and ideally with
>>>> some
>>>>>> PRs, as the hard part
>>>>>> is mostly done) those as well.
>>>>>>
>>>>>> Also, note that this is a PR against a branch so we could eventually
>>>> merge
>>>>>> it before adding support
>>>>>> for other arch/boards. And finally, I will provide documentation
>>>>>> to the
>>>>>> new build system in a separate
>>>>>> PR at some point, which I hope will ease the transition and help
>>>>>> reviewing.
>>>>>>
>>>>>> Best,
>>>>>> Matias
>>>>>>
>>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>>>>>>> A new issue is opened recently to address this topic:
>>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
>>>>>>> This proposal has the depth of the impact in our daily working,
>>>>>>> so it's
>>>>>>> very important to get the feedback from the community before the
>>>>>>> real
>>>>>>> action is taken.
>>>>>>> If you have any concern or suggestion, please reply to this email.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Xiang
>>>>>>>
Re: [Discuss] Migrate the build system to CMake
Posted by Sebastien Lorquet <se...@lorquet.fr>.
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 <acassis@gmail.com <mailto:acassis%40gmail.com>>
>> wrote:
>>
>>> I think we can divide the effort to port all the boards to the new CMake.
>>>
>>> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>>>
>>> Let see if we get more people involved in this effort.
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
>>>> Hi,
>>>> just wanted to add that until this is ready, the gap between master and
>>> the
>>>> branch
>>>> widens with every merged PR and this increases the backporting effort.
>>>> I'm willing to do most of the remaining work but as I mentioned I cannot
>>>> possibly test everything so
>>>> help is needed.
>>>> I'd really like your feedback on this before I continue and ensure the
>>>> effort will not go to waste.
>>>>
>>>> Best,
>>>> Matias
>>>>
>>>> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>>>>> Hi,
>>>>> for anyone not following the relevant PR, please have a look at the
>>>>> current state here:
>>>>>
>>>>> https://github.com/apache/incubator-nuttx/pull/3704
>>>>>
>>>>> This is now at a point where it can be tested by others. It would be
>>> very
>>>>> good to get some
>>>>> help testing what I got so far (sim and stm32f4discovery, both on Linux
>>>>> and mac), by running
>>>>> examples and test. There are some brief instructions at the end of the
>>> PR
>>>>> description for building.
>>>>>
>>>>> Other than that, I can continue porting other arch's and boards with the
>>>>> help of CI but it would be
>>>>> best if others with more boards could help testing (and ideally with
>>> some
>>>>> PRs, as the hard part
>>>>> is mostly done) those as well.
>>>>>
>>>>> Also, note that this is a PR against a branch so we could eventually
>>> merge
>>>>> it before adding support
>>>>> for other arch/boards. And finally, I will provide documentation to the
>>>>> new build system in a separate
>>>>> PR at some point, which I hope will ease the transition and help
>>>>> reviewing.
>>>>>
>>>>> Best,
>>>>> Matias
>>>>>
>>>>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>>>>>> A new issue is opened recently to address this topic:
>>>>>> https://github.com/apache/incubator-nuttx/issues/3455
>>>>>> This proposal has the depth of the impact in our daily working, so it's
>>>>>> very important to get the feedback from the community before the real
>>>>>> action is taken.
>>>>>> If you have any concern or suggestion, please reply to this email.
>>>>>>
>>>>>> Thanks
>>>>>> Xiang
>>>>>>
Re: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
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. <matias@imap.cc <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 <acassis@gmail.com <mailto:acassis%40gmail.com>
> >> <mailto:acassis%40gmail.com>>
> >> wrote:
> >>
> >> > I think we can divide the effort to port all the boards to the new
> >> > CMake.
> >> >
> >> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> >> >
> >> > Let see if we get more people involved in this effort.
> >> >
> >> > BR,
> >> >
> >> > Alan
> >> >
> >> > On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc> <mailto:matias%40imap.cc>> wrote:
> >> > > Hi,
> >> > > just wanted to add that until this is ready, the gap between master
> >> > > and
> >> > the
> >> > > branch
> >> > > widens with every merged PR and this increases the backporting
> >> > > effort.
> >> > > I'm willing to do most of the remaining work but as I mentioned I
> >> > > cannot
> >> > > possibly test everything so
> >> > > help is needed.
> >> > > I'd really like your feedback on this before I continue and ensure
> >> > > the
> >> > > effort will not go to waste.
> >> > >
> >> > > Best,
> >> > > Matias
> >> > >
> >> > > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> >> > >> Hi,
> >> > >> for anyone not following the relevant PR, please have a look at the
> >> > >> current state here:
> >> > >>
> >> > >> https://github.com/apache/incubator-nuttx/pull/3704
> >> > >>
> >> > >> This is now at a point where it can be tested by others. It would be
> >> > very
> >> > >> good to get some
> >> > >> help testing what I got so far (sim and stm32f4discovery, both on
> >> > >> Linux
> >> > >> and mac), by running
> >> > >> examples and test. There are some brief instructions at the end of
> >> > >> the
> >> > PR
> >> > >> description for building.
> >> > >>
> >> > >> Other than that, I can continue porting other arch's and boards with
> >> > >> the
> >> > >> help of CI but it would be
> >> > >> best if others with more boards could help testing (and ideally with
> >> > some
> >> > >> PRs, as the hard part
> >> > >> is mostly done) those as well.
> >> > >>
> >> > >> Also, note that this is a PR against a branch so we could eventually
> >> > merge
> >> > >> it before adding support
> >> > >> for other arch/boards. And finally, I will provide documentation to
> >> > >> the
> >> > >> new build system in a separate
> >> > >> PR at some point, which I hope will ease the transition and help
> >> > >> reviewing.
> >> > >>
> >> > >> Best,
> >> > >> Matias
> >> > >>
> >> > >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> >> > >>> A new issue is opened recently to address this topic:
> >> > >>> https://github.com/apache/incubator-nuttx/issues/3455
> >> > >>> This proposal has the depth of the impact in our daily working, so
> >> > >>> it's
> >> > >>> very important to get the feedback from the community before the
> >> > >>> real
> >> > >>> action is taken.
> >> > >>> If you have any concern or suggestion, please reply to this email.
> >> > >>>
> >> > >>> Thanks
> >> > >>> Xiang
> >> > >>>
> >> > >>
> >> > >
> >> >
> >>
> >
>
Re: [Discuss] Migrate the build system to CMake
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
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. <ma...@imap.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 <acassis@gmail.com
>> <mailto:acassis%40gmail.com>>
>> wrote:
>>
>> > I think we can divide the effort to port all the boards to the new
>> > CMake.
>> >
>> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>> >
>> > Let see if we get more people involved in this effort.
>> >
>> > BR,
>> >
>> > Alan
>> >
>> > On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
>> > > Hi,
>> > > just wanted to add that until this is ready, the gap between master
>> > > and
>> > the
>> > > branch
>> > > widens with every merged PR and this increases the backporting
>> > > effort.
>> > > I'm willing to do most of the remaining work but as I mentioned I
>> > > cannot
>> > > possibly test everything so
>> > > help is needed.
>> > > I'd really like your feedback on this before I continue and ensure
>> > > the
>> > > effort will not go to waste.
>> > >
>> > > Best,
>> > > Matias
>> > >
>> > > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>> > >> Hi,
>> > >> for anyone not following the relevant PR, please have a look at the
>> > >> current state here:
>> > >>
>> > >> https://github.com/apache/incubator-nuttx/pull/3704
>> > >>
>> > >> This is now at a point where it can be tested by others. It would be
>> > very
>> > >> good to get some
>> > >> help testing what I got so far (sim and stm32f4discovery, both on
>> > >> Linux
>> > >> and mac), by running
>> > >> examples and test. There are some brief instructions at the end of
>> > >> the
>> > PR
>> > >> description for building.
>> > >>
>> > >> Other than that, I can continue porting other arch's and boards with
>> > >> the
>> > >> help of CI but it would be
>> > >> best if others with more boards could help testing (and ideally with
>> > some
>> > >> PRs, as the hard part
>> > >> is mostly done) those as well.
>> > >>
>> > >> Also, note that this is a PR against a branch so we could eventually
>> > merge
>> > >> it before adding support
>> > >> for other arch/boards. And finally, I will provide documentation to
>> > >> the
>> > >> new build system in a separate
>> > >> PR at some point, which I hope will ease the transition and help
>> > >> reviewing.
>> > >>
>> > >> Best,
>> > >> Matias
>> > >>
>> > >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>> > >>> A new issue is opened recently to address this topic:
>> > >>> https://github.com/apache/incubator-nuttx/issues/3455
>> > >>> This proposal has the depth of the impact in our daily working, so
>> > >>> it's
>> > >>> very important to get the feedback from the community before the
>> > >>> real
>> > >>> action is taken.
>> > >>> If you have any concern or suggestion, please reply to this email.
>> > >>>
>> > >>> Thanks
>> > >>> Xiang
>> > >>>
>> > >>
>> > >
>> >
>>
>
Re: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
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 <acassis@gmail.com <mailto:acassis%40gmail.com>>
> wrote:
>
> > I think we can divide the effort to port all the boards to the new CMake.
> >
> > I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> >
> > Let see if we get more people involved in this effort.
> >
> > BR,
> >
> > Alan
> >
> > On 6/1/21, Matias N. <matias@imap.cc <mailto:matias%40imap.cc>> wrote:
> > > Hi,
> > > just wanted to add that until this is ready, the gap between master and
> > the
> > > branch
> > > widens with every merged PR and this increases the backporting effort.
> > > I'm willing to do most of the remaining work but as I mentioned I cannot
> > > possibly test everything so
> > > help is needed.
> > > I'd really like your feedback on this before I continue and ensure the
> > > effort will not go to waste.
> > >
> > > Best,
> > > Matias
> > >
> > > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> > >> Hi,
> > >> for anyone not following the relevant PR, please have a look at the
> > >> current state here:
> > >>
> > >> https://github.com/apache/incubator-nuttx/pull/3704
> > >>
> > >> This is now at a point where it can be tested by others. It would be
> > very
> > >> good to get some
> > >> help testing what I got so far (sim and stm32f4discovery, both on Linux
> > >> and mac), by running
> > >> examples and test. There are some brief instructions at the end of the
> > PR
> > >> description for building.
> > >>
> > >> Other than that, I can continue porting other arch's and boards with the
> > >> help of CI but it would be
> > >> best if others with more boards could help testing (and ideally with
> > some
> > >> PRs, as the hard part
> > >> is mostly done) those as well.
> > >>
> > >> Also, note that this is a PR against a branch so we could eventually
> > merge
> > >> it before adding support
> > >> for other arch/boards. And finally, I will provide documentation to the
> > >> new build system in a separate
> > >> PR at some point, which I hope will ease the transition and help
> > >> reviewing.
> > >>
> > >> Best,
> > >> Matias
> > >>
> > >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> > >>> A new issue is opened recently to address this topic:
> > >>> https://github.com/apache/incubator-nuttx/issues/3455
> > >>> This proposal has the depth of the impact in our daily working, so it's
> > >>> very important to get the feedback from the community before the real
> > >>> action is taken.
> > >>> If you have any concern or suggestion, please reply to this email.
> > >>>
> > >>> Thanks
> > >>> Xiang
> > >>>
> > >>
> > >
> >
>
Re: [Discuss] Migrate the build system to CMake
Posted by Nathan Hartman <ha...@gmail.com>.
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 <ac...@gmail.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. <ma...@imap.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: [Discuss] Migrate the build system to CMake
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
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. <ma...@imap.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: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
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: [Discuss] Migrate the build system to CMake
Posted by "Matias N." <ma...@imap.cc>.
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
>