Hi Greg, When I thought about this issue, my 'solution' was using NuttX as a library :-/
That would work for a single application, but we lose a lot in application architecture using the NuttX tree. Maybe porting using "same code"/different architectures would be advised as a not-recommended scenario for NuttX ... :-( Best regards, Flavio Em qua., 23 de fev. de 2022 às 00:00, Gregory Nutt <spudan...@gmail.com> escreveu: > > I think we have done a great job with C code compatibility across > platforms. I was thinking more of a common application make system that > could work on both Linux and NuttX platforms. The apps/ Makefiles and > Make.defs files and some of the apps Kconfig menu=ing are not compatible. > I would like to be able to just type 'make' and the app build would just do > the right thing. But in order to do that, the build system would have to > know which platform it is building on. > > Perhaps some indirect, ad hoc, heuristic like checking if TOPDIR and APPDIR > are defined. That would probably be enough. Those should always be passed > to the Makefile from the higher level apps/ build logic, but would never be > defined when building the application to run natively on Linux or any other > non-NuttX platform. > > Greg > > > > On Tue, Feb 22, 2022 at 8:31 PM James Dougherty <jafr...@gmail.com> wrote: > > > Hi Greg, > > > > Thanks for this; it is one of the greatest features you have built into > > NuttX - POSIX compliance!!! > > > > I have a few programs which compile either for NuttX or Linux/MacOS with no > > changes (or Makefile > > -D options). I started out that way, using -D__NuttX__ but then found that > > besides the includes for NuttX, > > almost all of the std c library and some of sys (at least filesystem/serial > > code) needs no change! > > > > Instead of gcc dumpspecs archaeology, I just did the opposite and have > > NuttX be the fall-out for > > conditional includes in the Posix environment. Most NuttX/Linux > > cross-platform code files have the below: > > > > #ifndef __linux__ > > #include <nuttx/config.h> /* NuttX */ > > #endif > > > > /* POSIX Includes (Linux/Nutt-X) common */ > > #include <stdint.h> > > #include <stdio.h> > > #include <string.h> > > #include <fcntl.h> > > #include <stdio.h> > > #include <stdlib.h> > > #include <unistd.h> > > #include <pthread.h> > > #include <math.h> > > #include <unistd.h> > > #include <dirent.h> > > #include <sys/ioctl.h> > > #include <stdlib.h> > > #include <sys/types.h> > > #include <sys/stat.h> > > #include <sys/statfs.h> > > #include <sys/ioctl.h> > > #include <sys/mount.h> > > #include <stdbool.h> > > #include <errno.h> > > #include <time.h> > > > > I also found some mutually exclusive cases like the below: > > > > #ifdef __linux__ > > /* Linux include -D__linux__ */ > > #else > > /* Nutt-X include -D__NuttX__ */ > > #endif > > > > And yes, I found __NuttX__ defined in the past also > > > > $find . -type f | xargs grep _NuttX__ > > ./nuttx/configs/stm32f4discovery/testlibcxx/Make.defs: > > -D__NuttX__ > > ./nuttx/configs/bambino-200e/netnsh/Make.defs:CXXFLAGS += $(ARCHDEFINES) > > $(EXTRADEFINES) -pipe -std=c++11 -DCLOCK_MONOTONIC -D__NuttX__ > > ./nuttx/configs/imxrt1050-evk/libcxxtest/Make.defs: -D__NuttX__ > > $ > > > > Of course if you're targeting more than one RTOS you'll need more, but I > > have had great luck with > > filesystem, pthread, mutex, and serial (termios) portability. > > > > Thank you > > -James > > > > > > > > > > > > > > On Tue, Feb 22, 2022 at 5:11 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > Hmm.. but that doesn't help with setting up the build. That definition > > is > > > only visible to C code since it is a C pre-processor definition defined > > in > > > the CFLAGS. It can't really be used to customize the build, at least not > > > in any clean way. > > > > > > It would have been useful to have a similar, Make=friendly definition as > > > well. > > > > > > On Tue, Feb 22, 2022 at 7:03 PM Gregory Nutt <spudan...@gmail.com> > > wrote: > > > > > > > Thanks! Now I see it defined tools/Config.mk. Looks like that was > > added > > > > with #2192. That is exactly what I need! > > > > > > > > I was thrown off because there are applications that ARE using > > __NUTTX__: > > > > > > > > $ grep -rl __NUTTX__ * > > > > system/adb/Makefile > > > > system/libuv/0001-initial-libuv-port-to-nuttx.patch > > > > system/libuv/libuv/Makefile > > > > system/libuv/tests/Makefile > > > > > > > > There are a couple using __NuttX__, but didn't catch those: > > > > > > > > $ grep -rl __NuttX__ * > > > > netutils/ftpd/ftpd.c > > > > netutils/webclient/webclient.c > > > > > > > > Thanks again. > > > > > > > > > > > > > > > > On Tue, Feb 22, 2022 at 6:43 PM Nathan Hartman < > > hartman.nat...@gmail.com > > > > > > > > wrote: > > > > > > > >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <spudan...@gmail.com> > > > wrote: > > > >> > > > >> > One option would be to define __NUTTX_ in tools/Config.mk instead of > > > in > > > >> > each individual apps/Makefile. That would provide a single point > > > >> > definition coordinate all usage. > > > >> > > > >> > > > >> Just one (possible) correction: IIRC it is capitalized as __NuttX__. > > All > > > >> my > > > >> cross platform applications look for __NuttX__ to detect that they are > > > >> being built this way. The buildroot toolchain does define that, > > though I > > > >> am > > > >> *not* using the buildroot toolchain and it is somehow defined anyway. > > I > > > am > > > >> away from my computer at the moment so I cannot check where it is > > coming > > > >> from, but from memory I think we added something to the NuttX build > > > >> scripts > > > >> some time ago (maybe about 1 or 2 years ago) to cause that to be > > defined > > > >> with all compilers. (Or perhaps I remember wrong and I added it to our > > > >> in-house boards' Make.defs.) > > > >> > > > >> Nathan > > > >> > > > > > > > > > -- Flavio de Castro Alves Filho flavio.al...@gmail.com Twitter: http://twitter.com/#!/fraviofii LinkedIn profile: www.linkedin.com/in/flaviocastroalves
