Hi Sebastien, 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.
Yes, we *should* expect that! But this isn't possible all the time, unfortunately. In general terms, the API is stable, but the required packages and libraries may change and this may eventually break the apps. The same occurs for applications in Windows, macOS and Linux: that's why we have package managers to deal with these requirements mess. Another common point of failure (far more common): `distclean` may not work if we change *nuttx* (os) or *nuttx-apps *version (again, this is expected because we have a list of files and folders to be cleaned that may not exist anymore). One thing that isn't clear enough (and perhaps we should add it to the documentation) is that `make distclean` should be called before changing one of those repositories. Otherwise, we would need to have a clean repository (`git clean -ffdx`) to make it *buildable* again. Best regards, Em sex., 31 de jan. de 2025 às 07:59, Sebastien Lorquet < sebast...@lorquet.fr> escreveu: > 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 > >>
