And yes, I was just commenting to someone the other day that NuttX is the only RTOS you can easily write your app on Linux and deploy with POSIX equivalent semantics on Nuttx. Great job, and Kudos to you and the whole NuttX team!
On Tue, Feb 22, 2022 at 7:48 PM James Dougherty <jafr...@gmail.com> wrote: > Right. you have to decide whether you want to build in an existing tree or > setup a new out of tree build > using sources pulled elsewhere. A simple (yet dangerous) way to do that in > GNU makefiles is to just override > vpath in a Makefile.linux, and then make -f GNUMakefile.linux from > wherever you are building: > > //Makefile.linux > # Find Nutt-X apps directory relative to where I am building from > CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ > else if [ -x /bin/bash ]; then echo /bin/bash; \ > else echo sh; fi ; fi) > SHELL := $(CONFIG_SHELL) > TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi) > APPSDIR := $(TOPDIR)/../.. > > > # pull in sources from nuttx appsdir > vpath %.c %.h $(APPSDIR)/pathing/to/file > > for a single top-level makefile with no children this works OK. > > > > On Tue, Feb 22, 2022 at 7:00 PM Gregory Nutt <spudan...@gmail.com> wrote: > >> 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 >> > > >> >> > > > >> > > >> > >> >
