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