Re: [DISCUSS] Out-of-tree builds should be standard?
NuttX supports two build system, when a new feature is added, three cases can happen: 1. Modify Makefile only 2. Modify CMakelist.txt only 3. Modify both Makefile and CMakelist.txt Since different people use different workflows, tools and have different priorities. What I suggest it that: 1. Spend your time to review the code and prompt the contributor update both build system at the same time 2. Improve CI to catch the mismatch automatically Only CI can ensure that your features never stop work. For example, Windows frequently fails the build since nobody spends time to set up Windows CI. CI always uses make before and cmake was added recently, so make is in a much better position than cmake from my statistics. On Fri, Aug 25, 2023 at 7:13 PM raiden00pl wrote: > > Yes, but this project has rules that were set by Greg. > > People have limited resources and the NuttX community is not numerous. > The question is what is more valuable for the project - adding > functionality supported > only by cmake, hoping someone will add support for make later, or not > adding any > functionality at all? > Is it against INVIOLABLES? Probably yes. > Is it better for the project? Probably yes. > Do we have the resources to act differently? Probably not. > > > This situation would not have happened if people had not introduced > > cmake in the first place > > Nobody is forcing anyone to use cmake. Nobody is forcing anyone to use > cmake-dependent features. You want cmake functionality in make but the > previous contributor didn't add it for some reason - feel free to add it, > but > don't force others to do your work for you. > Without cmake, there would be no nrf53, nrf91, dual core h7 and many others > that will soon appear due to easier integration with external projects and > easy > build for multiple images. ...Or they won't, if the integration with make > takes so > much time and irritation that contributors give up PRs to the upstream. > > pt., 25 sie 2023 o 12:35 Sebastien Lorquet > napisał(a): > > > Hi, > > > > Le 25/08/2023 à 11:48, raiden00pl a écrit : > > > Forcing people using cmake to support make is the worst thing that can > > > happen. > > > Open source is voluntary, any contribution is voluntary, any form of > > > forcing > > > others to do anything is unacceptable. > > > Modifying both systems will be good practice (and an act of kindness), > > but > > > only > > > if the contributor wants it. In other cases, a community interested in > a > > > particular > > > build system should take care of it. > > > > Yes, but this project has rules that were set by Greg. > > > > This situation would not have happened if people had not introduced > > cmake in the first place > > > > Sebastien > > > > >
Re: [DISCUSS] Out-of-tree builds should be standard?
> Yes, but this project has rules that were set by Greg. People have limited resources and the NuttX community is not numerous. The question is what is more valuable for the project - adding functionality supported only by cmake, hoping someone will add support for make later, or not adding any functionality at all? Is it against INVIOLABLES? Probably yes. Is it better for the project? Probably yes. Do we have the resources to act differently? Probably not. > This situation would not have happened if people had not introduced > cmake in the first place Nobody is forcing anyone to use cmake. Nobody is forcing anyone to use cmake-dependent features. You want cmake functionality in make but the previous contributor didn't add it for some reason - feel free to add it, but don't force others to do your work for you. Without cmake, there would be no nrf53, nrf91, dual core h7 and many others that will soon appear due to easier integration with external projects and easy build for multiple images. ...Or they won't, if the integration with make takes so much time and irritation that contributors give up PRs to the upstream. pt., 25 sie 2023 o 12:35 Sebastien Lorquet napisał(a): > Hi, > > Le 25/08/2023 à 11:48, raiden00pl a écrit : > > Forcing people using cmake to support make is the worst thing that can > > happen. > > Open source is voluntary, any contribution is voluntary, any form of > > forcing > > others to do anything is unacceptable. > > Modifying both systems will be good practice (and an act of kindness), > but > > only > > if the contributor wants it. In other cases, a community interested in a > > particular > > build system should take care of it. > > Yes, but this project has rules that were set by Greg. > > This situation would not have happened if people had not introduced > cmake in the first place > > Sebastien > >
Re: [DISCUSS] Out-of-tree builds should be standard?
Hi, Le 25/08/2023 à 11:48, raiden00pl a écrit : Forcing people using cmake to support make is the worst thing that can happen. Open source is voluntary, any contribution is voluntary, any form of forcing others to do anything is unacceptable. Modifying both systems will be good practice (and an act of kindness), but only if the contributor wants it. In other cases, a community interested in a particular build system should take care of it. Yes, but this project has rules that were set by Greg. This situation would not have happened if people had not introduced cmake in the first place Sebastien
RE: [DISCUSS] Out-of-tree builds should be standard?
Hi, I think that we should prioritize the compatibility and standardization otherwise the NuttX developer experience may varry (depend on “luck”) for some platforms Best regards Alin From: raiden00pl Sent: den 25 augusti 2023 11:49 To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Out-of-tree builds should be standard? I think this is reinventing the wheel. This seems to not be a trivial change, and the ready solution in the form of cmake is already there. If an individual or a company wants to devote their time to it, I don't see a problem, but this must ZjQcmQRYFpfptBannerStart This message is from an unknown sender You have not previously corresponded with this sender and they are external to Sony ZjQcmQRYFpfptBannerEnd I think this is reinventing the wheel. This seems to not be a trivial change, and the ready solution in the form of cmake is already there. If an individual or a company wants to devote their time to it, I don't see a problem, but this must be backward compatible. The main voice against cmake was that it destroys external projects and people's workflows. If this change is supposed to do the same thing then I don't see the point in it. > In the GitHub comments, it was mentioned that we should not make cmake > mandatory for certain boards Forcing people using cmake to support make is the worst thing that can happen. Open source is voluntary, any contribution is voluntary, any form of forcing others to do anything is unacceptable. Modifying both systems will be good practice (and an act of kindness), but only if the contributor wants it. In other cases, a community interested in a particular build system should take care of it. czw., 24 sie 2023 o 21:55 Tomek CEDRO mailto:to...@cedro.info>> napisał(a): > Out-of-tree build is the default for me in various projects. I like to > have git submodules / dependencies untouched. > > FreeBSD uses (BSD) make and allows out of tree builds and it is > possible to specify WRKDIRPREFIX for instance in tmpfs located in RAM. > Kernel build also allows passing another variable with specific > configuration. So various kernels can be built into different > locations. This should be possible also with make in NuttX..? :-) > > I use custom board and custom application (that requires linking to > nuttx-apps) to build NuttX anyways by default. Then my build script > copies resulting binary to out of tree bin dir appending timestamp > suffix to the firmware image ready to flash. NuttX sources and app > sources are git submodules that can be easily updated / changed to a > specific version / branch / commit / release. This enables various > automation scenarios. > > This is the layout: > > project.git/ > nuttx.git > nuttx-apps.git > cederom/boards/myboard > cederom/apps/myapp > bin > scripts > doc > > Above could be extended with "build/board_cfg" location with all > configuration and build files specific for a given board..? This > location could be provided and set custom in WRKDIRPREFIX env variable > so the sources remain untouched..? > > Alternatively, at this point, user can simply have two nuttx.git > subdirectories (i.e. project/nuttx-cm4 and project/nuttx-cm7) with > build configuration and binaries for each CPU right? I do not know the > details of linking in that situation though. > > This is interesting problem, as I also have some prototype Maxim MCU > with ARM Cortex M as main CPU and modified RISC-V as Hardware Neural > Network Accelerator. This is something new. I wonder how the story > follows :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info<http://www.tomek.cedro.info> >
Re: [DISCUSS] Out-of-tree builds should be standard?
I think this is reinventing the wheel. This seems to not be a trivial change, and the ready solution in the form of cmake is already there. If an individual or a company wants to devote their time to it, I don't see a problem, but this must be backward compatible. The main voice against cmake was that it destroys external projects and people's workflows. If this change is supposed to do the same thing then I don't see the point in it. > In the GitHub comments, it was mentioned that we should not make cmake > mandatory for certain boards Forcing people using cmake to support make is the worst thing that can happen. Open source is voluntary, any contribution is voluntary, any form of forcing others to do anything is unacceptable. Modifying both systems will be good practice (and an act of kindness), but only if the contributor wants it. In other cases, a community interested in a particular build system should take care of it. czw., 24 sie 2023 o 21:55 Tomek CEDRO napisał(a): > Out-of-tree build is the default for me in various projects. I like to > have git submodules / dependencies untouched. > > FreeBSD uses (BSD) make and allows out of tree builds and it is > possible to specify WRKDIRPREFIX for instance in tmpfs located in RAM. > Kernel build also allows passing another variable with specific > configuration. So various kernels can be built into different > locations. This should be possible also with make in NuttX..? :-) > > I use custom board and custom application (that requires linking to > nuttx-apps) to build NuttX anyways by default. Then my build script > copies resulting binary to out of tree bin dir appending timestamp > suffix to the firmware image ready to flash. NuttX sources and app > sources are git submodules that can be easily updated / changed to a > specific version / branch / commit / release. This enables various > automation scenarios. > > This is the layout: > > project.git/ > nuttx.git > nuttx-apps.git > cederom/boards/myboard > cederom/apps/myapp > bin > scripts > doc > > Above could be extended with "build/board_cfg" location with all > configuration and build files specific for a given board..? This > location could be provided and set custom in WRKDIRPREFIX env variable > so the sources remain untouched..? > > Alternatively, at this point, user can simply have two nuttx.git > subdirectories (i.e. project/nuttx-cm4 and project/nuttx-cm7) with > build configuration and binaries for each CPU right? I do not know the > details of linking in that situation though. > > This is interesting problem, as I also have some prototype Maxim MCU > with ARM Cortex M as main CPU and modified RISC-V as Hardware Neural > Network Accelerator. This is something new. I wonder how the story > follows :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: [DISCUSS] Out-of-tree builds should be standard? -> no
On Fri, Aug 25, 2023 at 9:38 AM Sebastien Lorquet wrote: > If you need to build twice, build twice, one project for h7, one project > for m4, then one python or other script to combine the images. Some thoughts on this part :-) Yes, I agree here, and also proposed that with a several examples. New script would be a proof of concept if that kind of build is possible and how things work in reality. New script would be addition and non invasive functionality. New script would not flip all make build system upside down with a possibility of breaking backwards compatibility because build system remains untouched. New build script may create out-of-tree copy of the sources and configuration for a specific make build then link the results into a single firmware image. New script may leverage new cmake build with out-of-tree objects and binaries if make build is not good enough. New script, when verified and accepted, can be added to the upstream, providing additional optional functionality, just as most new things are added - use only when needed and stay in harmony with what is already here. I also use build scripts in my projects. New script is a good first step to prove if this kind of build is possible. If that works and author has time to update make build system with a new out-of-tree features _that_will_not_break_anything_ and _provide_full_backwards_compatibility_ (I gave FreeBSD build system as an example) that would seem to be time to discuss the _non_breaking_ change when we have something to discuss on. But this seems really lots of work that can be spared with a simple additional optional script. There are lots of ways to achieve the goal, in theory anything is possible, in reality it is always matter of work-time-cost. Not sure if that sounded clear enough in my previous reply, but this kind of build seems already possible, I work that way, with a different approach to build and project organization and zero upstream modifications. Why change the defaults for everyone because of a specific setup? Defaults should stay untouched :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [DISCUSS] Out-of-tree builds should be standard? -> no
Others selected parts of inviolables.txt : All support must apply equally to all supported platforms. At present this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu, Windows native, macOS, Solaris, and FreeBSD. No tool/environment solutions will be considered that limit the usage of NuttX on any of the supported platforms. Inclusive rather than exclusive. Hobbyists are valued users of the OS including retro computing hobbyists and DIY “Maker” hobbyists. No changes to build system should limit use of NuttX by any user. We must resist the pull to make NuttX into a Linux-only, GCC-only, and ARM-only solution. So the question asked in this thread should be answered : No, out of tree builds should not be standard. Sebastien Le 25/08/2023 à 09:38, Sebastien Lorquet a écrit : Hello Why should you change the experience and make life difficult for everyone, just to support a pair of specific configuration? If you need to build twice, build twice, one project for h7, one project for m4, then one python or other script to combine the images. All users matter (eg, not just the little comfort of AMP users) This is in inviolables.txt Sebastien Le 24/08/2023 à 21:28, Nathan Hartman a écrit : PR # 10328 is bringing support for STM32 MCUs that have two different kinds of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style (Asymmetric Multi Processing) chip. This requires building NuttX twice, once for each core, with two different configs. In the GitHub comments, it was mentioned that we should not make cmake mandatory for certain boards, and then mentioned that with make the problem is that you have to make distclean between the two builds. Copying the comments here: slorquet writes: It would be good to avoid cmake-specific features. Is make a supported build system or was it deprecated? If it's supported no feature should work only with cmake. Thanks. xiaoxiang781216 writes: The change should work with make too. But make doesn't support out of tree build, it's very annoying to develop AMP system like this patch because you have to `make distclean` and `make` every time. This makes me wonder whether we should consider making out-of-tree builds the blessed way to build, with both make and cmake. I realize that this might disrupt many people's builds -- including myself. I have been building in-tree from the start, so this will require me to change my workflows. However, after the dust settles, this could have several advantages: 1. Not polluting the source tree with build artifacts and temporary files. 2. Simplifying the.gitignore rules throughout. 3. Allowing AMP builds and builds for multiple different boards without make distclean. To switch between boards, just change to a different build dir. I am starting this thread here because this kind of proposal really needs a discussion on the mailing list. Thoughts? Cheers Nathan
Re: [DISCUSS] Out-of-tree builds should be standard? -> no
Hello Why should you change the experience and make life difficult for everyone, just to support a pair of specific configuration? If you need to build twice, build twice, one project for h7, one project for m4, then one python or other script to combine the images. All users matter (eg, not just the little comfort of AMP users) This is in inviolables.txt Sebastien Le 24/08/2023 à 21:28, Nathan Hartman a écrit : PR # 10328 is bringing support for STM32 MCUs that have two different kinds of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style (Asymmetric Multi Processing) chip. This requires building NuttX twice, once for each core, with two different configs. In the GitHub comments, it was mentioned that we should not make cmake mandatory for certain boards, and then mentioned that with make the problem is that you have to make distclean between the two builds. Copying the comments here: slorquet writes: It would be good to avoid cmake-specific features. Is make a supported build system or was it deprecated? If it's supported no feature should work only with cmake. Thanks. xiaoxiang781216 writes: The change should work with make too. But make doesn't support out of tree build, it's very annoying to develop AMP system like this patch because you have to `make distclean` and `make` every time. This makes me wonder whether we should consider making out-of-tree builds the blessed way to build, with both make and cmake. I realize that this might disrupt many people's builds -- including myself. I have been building in-tree from the start, so this will require me to change my workflows. However, after the dust settles, this could have several advantages: 1. Not polluting the source tree with build artifacts and temporary files. 2. Simplifying the.gitignore rules throughout. 3. Allowing AMP builds and builds for multiple different boards without make distclean. To switch between boards, just change to a different build dir. I am starting this thread here because this kind of proposal really needs a discussion on the mailing list. Thoughts? Cheers Nathan
Re: [DISCUSS] Out-of-tree builds should be standard?
Out-of-tree build is the default for me in various projects. I like to have git submodules / dependencies untouched. FreeBSD uses (BSD) make and allows out of tree builds and it is possible to specify WRKDIRPREFIX for instance in tmpfs located in RAM. Kernel build also allows passing another variable with specific configuration. So various kernels can be built into different locations. This should be possible also with make in NuttX..? :-) I use custom board and custom application (that requires linking to nuttx-apps) to build NuttX anyways by default. Then my build script copies resulting binary to out of tree bin dir appending timestamp suffix to the firmware image ready to flash. NuttX sources and app sources are git submodules that can be easily updated / changed to a specific version / branch / commit / release. This enables various automation scenarios. This is the layout: project.git/ nuttx.git nuttx-apps.git cederom/boards/myboard cederom/apps/myapp bin scripts doc Above could be extended with "build/board_cfg" location with all configuration and build files specific for a given board..? This location could be provided and set custom in WRKDIRPREFIX env variable so the sources remain untouched..? Alternatively, at this point, user can simply have two nuttx.git subdirectories (i.e. project/nuttx-cm4 and project/nuttx-cm7) with build configuration and binaries for each CPU right? I do not know the details of linking in that situation though. This is interesting problem, as I also have some prototype Maxim MCU with ARM Cortex M as main CPU and modified RISC-V as Hardware Neural Network Accelerator. This is something new. I wonder how the story follows :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
[DISCUSS] Out-of-tree builds should be standard?
PR # 10328 is bringing support for STM32 MCUs that have two different kinds of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style (Asymmetric Multi Processing) chip. This requires building NuttX twice, once for each core, with two different configs. In the GitHub comments, it was mentioned that we should not make cmake mandatory for certain boards, and then mentioned that with make the problem is that you have to make distclean between the two builds. Copying the comments here: slorquet writes: > > It would be good to avoid cmake-specific features. > > > > > > Is make a supported build system or was it deprecated? > > > > > > If it's supported no feature should work only with cmake. Thanks. xiaoxiang781216 writes: > The change should work with make too. But make doesn't support out of tree build, it's very annoying to develop AMP system like this patch because you have to `make distclean` and `make` every time. This makes me wonder whether we should consider making out-of-tree builds the blessed way to build, with both make and cmake. I realize that this might disrupt many people's builds -- including myself. I have been building in-tree from the start, so this will require me to change my workflows. However, after the dust settles, this could have several advantages: 1. Not polluting the source tree with build artifacts and temporary files. 2. Simplifying the.gitignore rules throughout. 3. Allowing AMP builds and builds for multiple different boards without make distclean. To switch between boards, just change to a different build dir. I am starting this thread here because this kind of proposal really needs a discussion on the mailing list. Thoughts? Cheers Nathan
