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 > > >> > > > > > >
