hello
My proposal is:
1) define how the app build system is invoked and never move that
2) define that nuttx expects apps in a particular file at a particular
place and never move that.
Also, enfore the use of the posix api everywhere. that should be enough...
the app/os limit is probably in the inviolables... (I did not check)
Sebastien
On 31/01/2025 16:20, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 3:35 PM <michal.lyszc...@bofc.pl> wrote:
On 2025-01-31 13:48:32, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet <sebast...@lorquet.fr> wrote:
Of course I also tried with the commit before that one, and it didnt
work either.
Sebastien, did you try the release packages? Does the problem occur in
the release packages?
Upstream master is for development purposes, things may get broken for
a while, I would never put my product on a master branch.
This is offloading responsibility to end user. Sebastian is right here.
Either apps are separated properly so that even 1 year old apps repo will work
with current HEAD of rtos, or nuttx should have sync mechanism like submodules
(don't go there) or tool like Zephyr's west to sync it (or it can also be
done with make/cmake).
Did you ever try to bisect problem in nuttx? Constant failures in apps and you
have to manually guess which commit is going to at least compile - and then you
still cannot be 100% sure soft does/doesn't work as indended.
Hmm, I get it. I saw that too. I thought it should be always in sync.
I saw changes in either nuttx or nuttx-apps that depends on each
other. Not sure if that would allow apps to build / work on one year
old rtos code.
So what are your solution propositions?
1. Prevent nuttx-apps modification when something changes on nuttx
side that would break backward rtos compatibility? How to make updates
then?
2. Add CI action that would build nuttx-apps on older nuttx to make
sure compatibility is maintained? What if build fails and update is
necessary?
3. Extend CI build of all possible apps and see how nuttx change
impacts nuttx-apps side in depth and what needs an update too? But
then still we have no compatibility as apps will be updated too.
Usually OS has something called API and apps must adhere to that API.
If breaking change is introduced API number is bumped and so apps
needs an update.
We should discuss and vote this kind of design decision and put inside
CONTRIBUTING and documentation f anything changes.
Also I welcome everyone to help in PR review if changes are impacting
you, catch them first before merge :-)
Looking at documentation:
https://nuttx.apache.org/docs/latest/quickstart/install.html
Apache NuttX is actively developed on GitHub. There are two main
repositories, nuttx and apps, where the latter is technically optional
(but recommended for complete set of features). If you intend to
contribute changes, you need the absolute latest version or you simply
prefer to work using git, you should clone these repositories
(recommended). Otherwise you can choose to download any stable release
archive.
There is no mention that current apps code guarantee compatibility
with older rtos versions code. Instruction says either use "absolute
latest version", "clone repositories", "otherwise you can choose to
download any stable release archive". For me it means I need to have
both nuttx and nuttx-apps in sync or use release packages.
Greg what you think? :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
