Application.mk was not up to date. hah.
The application repository should be independent from the main nuttx
repo, right? and should continue to work even if nuttx is updated,
right? Thats a reasonable expectation, right? but this is clearly not
the case.
This is a clear breakage of the os/app interface.
Keeping this interface stable would help A LOT to keep custom boards
working while nuttx works.
Can you make this a project rule?
Dont break the apps build system when the os build system is updated.
How to do that? Dont change the place where the OS expects libapps.a.
Make it fixed, and DONT CHANGE IT.
Now I'm facing the next bug. See the problem here? See why I'm getting
mad? It never ends. I spent another half day on this. Not working yet.
Fortunately after the bisection I am now on the master branch.
IN: binfmt/libbinfmt.a -> staging/libbinfmt.a
make[1] : on entre dans le répertoire
« /home/slo/Sources/ccv5-env/nuttx/arch/arm/src »
make[2] : on entre dans le répertoire
« /home/slo/Sources/ccv5-env/ccv5/board/src »
make[2]: *** Aucune règle pour fabriquer la cible « libboard.a ». Arrêt.
make[2] : on quitte le répertoire
« /home/slo/Sources/ccv5-env/ccv5/board/src »
make[1]: *** [Makefile:184 : board/libboard.a] Erreur 2
make[1] : on quitte le répertoire
« /home/slo/Sources/ccv5-env/nuttx/arch/arm/src »
make: *** [tools/Unix.mk:552 : nuttx] Erreur 2
Sebastien
On 31/01/2025 10:57, Sebastien Lorquet wrote:
Can you believe it?
After fixing all these apps so they talk with this OS, THE APPS BUILD
SYSTEM IS BROKEN
IN: /home/slo/Sources/product-env/product/apps/libapps.a ->
staging/libapps.a
install -m 0644 /home/slo/Sources/product-env/product/apps/libapps.a
staging/libapps.a
install: impossible d'évaluer
'/home/slo/Sources/product-env/product/apps/libapps.a': Aucun fichier
ou dossier de ce type
make: *** [tools/LibTargets.mk:235 : staging/libapps.a] Erreur 1
This kind of string of problems really makes me mad, and sad, and is
about to make me miss very important project deadlines.
dont be surprised that I dont trust nuttx anymore.
all your lengthy build tests are for nothing if you dont check and
apps and os work together all the time!
Sebastien
On 31/01/2025 10:30, Sebastien Lorquet wrote:
No rant here just facts, of the kind that makes my head explode.
Many problems arise when the nuttx and nuttx-apps are not in sync.
This should not happen, because nuttx sort-of promises an os/app
separation, and I dont think it is actually enforced.
I'm not talking about internal interfaces here.
One example I am trying to fix right now is realpath, that at some
point was lib_realpath
There are many examples like this. There is one below.
I think that testing some different combination of nuttx and apps
repositories would unearth a huge number of compatibility problems.
Instead of adding new features, these problems should be fixed with
high priority, and not just for me.
Example : these repositories versions dont work together for stm32f4.
slo@slolin:~/Sources/product-env/nuttx$ cd ../apps
slo@slolin:~/Sources/product-env/apps$ git log -1
commit 66231194be3de611c18bfaa2e63eece604184041 (HEAD)
Author: chao an <anc...@lixiang.com>
Date: Fri Dec 27 14:20:37 2024 +0800
apps/system: replace CONFIG_NSH_LINELEN to LINE_MAX
Applications should not depend on any properties of nshlib
Signed-off-by: chao an <anc...@lixiang.com>
slo@slolin:~/Sources/product-env/apps$ cd ../nuttx
slo@slolin:~/Sources/product-env/nuttx$ git log -1
commit 05b101134a9c33959068b5892c3405a31a6fec9e (HEAD -> product,
origin/product)
Author: liqinhui <liqin...@xiaomi.com>
Date: Thu May 9 15:55:24 2024 +0800
net:Support jumbo frame prealloc the iob for the ICMP/UDP/TCP.
For the ICMP, UDP and TCP, pre-alloc an iob for a jumbo frame.
Signed-off-by: liqinhui <liqin...@xiaomi.com>
Sebastien
