hello
you are right, let's try:
12.8.0 -> configure broken
12.7.0 -> configure works
apps is copied from master.
CC: nsh_alias.c
In file included from nsh_alias.c:39:
nsh_console.h:191:18:error: 'LINE_MAX' undeclared here (not in a
function); did you mean 'LINK_MAX'?
191 | char cn_line[LINE_MAX];
| ^~~~~~~~
| LINK_MAX
OK so I cant use master apps
switching my apps to 12.7.0
ok every code is from 12.7 now
arm-none-eabi-ar rcs libbinfmt.a binfmt_globals.o
binfmt_initialize.o binfmt_register.o binfmt_unregister.o
binfmt_loadmodule.o binfmt_unloadmodule.o binfmt_execmodule.o
binfmt_exec.o binfmt_copyargv.o binf
mt_copyactions.o binfmt_dumpmodule.o binfmt_coredump.o builtin.o
make[1] : on quitte le répertoire
« /home/slo/Sources/product-env/nuttx/binfmt »
IN: binfmt/libbinfmt.a -> staging/libbinfmt.a
make[1] : on entre dans le répertoire
« /home/slo/Sources/product-env/nuttx/arch/arm/src »
make[2] : on entre dans le répertoire
« /home/slo/Sources/product-env/product/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/product-env/product/board/src »
make[1]: *** [Makefile:182 : board/libboard.a] Erreur 2
make[1] : on quitte le répertoire
« /home/slo/Sources/product-env/nuttx/arch/arm/src »
make: *** [tools/Unix.mk:551 : nuttx] Erreur 2
boom. what is libboard? we never met before.
so your official 12.7.0 release cannot be used. The same problem happen
when I use 12.8 or master if I bypass the silly sed thing in configure.
Probably something is not right anymore in my board makefile.
Do you realize how complex it is to use nuttx on the long term? The
amount of things to keep in mind to keep everything working is getting
larger and larger. That I can understand.
And there are no migration guides. Maybe that could help? I would be ok
to stay on releases if you told me what to change in my custom board so
my 12.6 board will work in 12.7.
But that would require coordination with the authors of the thousands of
commits in each release. Could that be automated if you forced every
pull request to include migration documentation if that pull request
changes any critical Make.defs or Makefile?
Meanwhile my project still does not build and I still cant test the
keepalive fixes. so many side quests lol
Sebastien
On 31/01/2025 17:25, Nathan Hartman wrote:
On Fri, Jan 31, 2025 at 7:50 AM Tomek CEDRO<to...@cedro.info> 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.
I concur with this.
Products should be based on official releases. That's why we make releases.
You don't have to use release tarballs. You could base your work on the
release branch if you need to add customizations.
There are a few months between releases. This means that if you cannot
invest the time and effort to participate in day to day development, you
could instead opt to spend a much less amount of time, just once per
release cycle, to help with testing the release candidates and reporting
breakage before the release becomes official. That will result in much
better quality releases. It will also give you a few months at a time of
total stability with no or very few upstream changes, and those changes
would only be bugfixes or security.
While the master branch *should* be kept as stable as possible, it should
*not* be a substitute for releases.
Hope this helps,
Nathan
