Hi, My answers are in the quote...
On Mon 28 Jul 2025 10:07:20 AM , Ludovic Vanasse wrote: > 1. I'm also interested to use Nix for the development environment, and I > was initially leaning on using the devenv.sh tool instead of doing > straight with Nix. My rational was that it will help non-initiated to Nix > to learn about it and be more at ease with its concepts and > functionalities. So, I'm wondering why did you decide to go with Nix > directly? Is your team already using Nix elsewhere and doesn't need to ramp > up from the learning curve? And I was thinking of maybe upstreaming that to > the NuttX community or at least sharing that it was something we've been > using and might prove useful for others. It is actually because we are using it elsewhere and also not. 😅 The development environment for NuttX was the first use for Nix that I introduced in our company. At that point it was rather "set and forget" arrangement for the rest of the team and thus there was no reason to add another layer as I wasn't expecting anyone to ticker with it that much. The instructions were: "Install Nix and run nix develop in the directory". I am using NixOS on my PCs and routers and thus it was more natural for me to use Nix directly. I also have my reservations with devenv. Subsequently Nix got introduced to CI, tooling servers, and lastly to the embedded Linux. I would be laying saying that it was smooth sailing and actually most of the issues and resentment was because of the Nix language. It's just not a good language to use, but I still think that it is better to be closer to the source of the packages instead of working in some higher level abstraction. > 2. I'm wondering why not use the custom board and custom application > folders structure that's provided by the NuttX build system? I'm wondering > what do you gain from doing that? I'm asking because I'm starting a NuttX > project at my workplace and I decided to simply follow what the > documentation was offering, and I'm also not very much expose to Meson, so > some benefits might not be directly obvious to me. It is actually using the custom board and external applications as described by NuttX documentation. The difference is in the configuration. I consider the minified Kconfig configuration as not a good practice for the long term project maintenance. Instead our configuration script generates `.config` file based on the pinned configuration that are checked after kconfig-oldconfig. This way we have commented and organized configuration file that can be maintained even between NuttX updates. It has also advantage that we can have multiple configuration files merged (we have `defconfig` as base, `appconfig` for firmware, and `bootloaderconfig` for nxboot where latter two are extending the base). That is why we do not use `./tools/configure.sh`. Otherwise the setup is pretty much as documented by NuttX. And on the topic of Meson. If you are planning on developing NuttX centric apps without much external dependencies then it might be overkill for you. Meson makes sense for us because we have other projects like LVGLUI (our UI library on top of LVGL), SHVC (https://gitlab.com/silicon-heaven/shvc), logging library, and more that are included as Meson subprojects. All of them use Meson and are tested on Linux under Valgrind. We are also splitting functionality to multiple applications that are communicating over broker which gives us ability to develop those that are not hardware dependent (like UI app) on the PC but with a real data from the board and for that we use Meson to build Linux version of the app. It really depends on your use case. > Thank you again for sharing this, it is very much appreciated. > > Best regards, > > Ludovic Vanasse > ludovicvana...@gmail.com > > > On Mon, Jul 28, 2025 at 9:02 AM Karel Kočí <cyn...@email.cz> wrote: > > > Hi all, > > > > I want to share with the whole community a setup we are using at > > Elektroline to > > develop firmwares with NuttX. The setup is pretty complex but provides us > > with > > ability to maintain project's applications under Meson build system, > > compile > > them for testing on other Unix-like platforms, and perform automated > > testing in > > CI (not included in the template). The repository with demonstration is in > > here: > > > > https://gitlab.com/Cynerd/nuttx-meson-template/ > > > > Conceptually the root matches the Meson project structure and everything > > that is > > NuttX related is in `nuttx` directory. The directory `nuttx/board` matches > > the > > board support directory just like in NuttX repository. > > > > One speciality is Kconfig configuration that is generated by > > `nuttx/tools/nuttx-config.sh` and thus `nuttx/board/configs/defconfig` > > rather > > contains only hand written rules. This is a different approach compared to > > the > > NuttX suggested one where we hand write configuration we want instead of > > creating one and minifying it. > > > > Meson project in the root is included by `nuttx/project-apps/meson-apps`. > > That > > is NuttX application that configures Meson build to use the same compiler > > and > > flags as NuttX and includes Meson compiled object files in the NuttX build. > > > > Feel free to inspire yourself, comment our setup, or share your own. > > > > With regards, > > Karel Kočí > >
signature.asc
Description: PGP signature
