You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Gregory Nutt <sp...@gmail.com> on 2022/02/22 18:50:22 UTC
I does an app know it is building on NuttX
I have been working on an application for the past several months. Now
want to get it running on NuttX. I don't have much experience porting
applications to NuttX and have some dumb newbie questions (I mostly worked
on the other side of the application/OS interface).
If I have an application that builds and runs on Linux and I want to port
it to NuttX, I would basically just provide the Kconfig files, Make.defs
files, and Makefiles as expected by the build system, then just link my
application anywhere in the app/ source tree.
But how does the code know that it is running on NuttX? There is no
CONFIG_NUTTX, there is no OS_managed __NUTTX__ definition.
I do see a __NUTTX__ definition defined in some application Makefiles in
apps/, but this is a chicken'n'egg problem. They use custom Makefiles to
provide these definitions. But what if you want the same application build
logic to support either platform. I don't see any way to do that.
Has anyone thought of way to do this? Or do you all use custom Makefile
for the NuttX build?
Greg
Re: I does an app know it is building on NuttX
Posted by Gregory Nutt <sp...@gmail.com>.
Yes, exactly. That is why I said that that solution ws "not one that is
easily fielded". The situation would be exactly as it is with Linux. You
can't use any toolchain to build Linux, you have to use one with a name
like arm-linux-eabi or xxx-linux-elf. It is mandatory for Linux.
And that is where __Linux__ is defined: In the xxx-linux-xxx toolchain.
So it is THE standard solution but not one many people who have favorite
toolchains would like.
On Tue, Feb 22, 2022 at 1:31 PM Piet <m0...@mailbox.org.invalid> wrote:
> Wouldn‘t the buildroot option require, that all targets needs to be
> supported from that single toolchain unless the not supported target
> defined __NUTTX__ within their own configs?
>
> /Piet
>
>
>
>
> > Am 22.02.2022 um 20:14 schrieb Gregory Nutt <sp...@gmail.com>:
> >
> > 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.
> >
> > My favorite solution, but not one that is easily fielded would be to use
> > the NuttX buildroot toolchains:
> > https://bitbucket.org/nuttx/buildroot/src/master/ . These generate a
> > nuttx-eab-gcc (toolchain not a none-eabi toolchain) and they have several
> > advantages: (1) they do not use a foreign libc but build directly using
> > the NuttX libc. So they will never generate libc header file conflicts.
> > and (1) they define __NUTTX__
> >
> > The downside is that, as I recall, they don't build the C++ standard
> > library.
> >
> >
> >> On Tue, Feb 22, 2022 at 12:50 PM Gregory Nutt <sp...@gmail.com>
> wrote:
> >>
> >> I have been working on an application for the past several months. Now
> >> want to get it running on NuttX. I don't have much experience porting
> >> applications to NuttX and have some dumb newbie questions (I mostly
> worked
> >> on the other side of the application/OS interface).
> >>
> >> If I have an application that builds and runs on Linux and I want to
> port
> >> it to NuttX, I would basically just provide the Kconfig files, Make.defs
> >> files, and Makefiles as expected by the build system, then just link my
> >> application anywhere in the app/ source tree.
> >>
> >> But how does the code know that it is running on NuttX? There is no
> >> CONFIG_NUTTX, there is no OS_managed __NUTTX__ definition.
> >>
> >> I do see a __NUTTX__ definition defined in some application Makefiles in
> >> apps/, but this is a chicken'n'egg problem. They use custom Makefiles
> to
> >> provide these definitions. But what if you want the same application
> build
> >> logic to support either platform. I don't see any way to do that.
> >>
> >> Has anyone thought of way to do this? Or do you all use custom Makefile
> >> for the NuttX build?
> >>
> >> Greg
> >>
> >>
>
Re: I does an app know it is building on NuttX
Posted by Piet <m0...@mailbox.org.INVALID>.
Wouldn‘t the buildroot option require, that all targets needs to be supported from that single toolchain unless the not supported target defined __NUTTX__ within their own configs?
/Piet
> Am 22.02.2022 um 20:14 schrieb Gregory Nutt <sp...@gmail.com>:
>
> 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.
>
> My favorite solution, but not one that is easily fielded would be to use
> the NuttX buildroot toolchains:
> https://bitbucket.org/nuttx/buildroot/src/master/ . These generate a
> nuttx-eab-gcc (toolchain not a none-eabi toolchain) and they have several
> advantages: (1) they do not use a foreign libc but build directly using
> the NuttX libc. So they will never generate libc header file conflicts.
> and (1) they define __NUTTX__
>
> The downside is that, as I recall, they don't build the C++ standard
> library.
>
>
>> On Tue, Feb 22, 2022 at 12:50 PM Gregory Nutt <sp...@gmail.com> wrote:
>>
>> I have been working on an application for the past several months. Now
>> want to get it running on NuttX. I don't have much experience porting
>> applications to NuttX and have some dumb newbie questions (I mostly worked
>> on the other side of the application/OS interface).
>>
>> If I have an application that builds and runs on Linux and I want to port
>> it to NuttX, I would basically just provide the Kconfig files, Make.defs
>> files, and Makefiles as expected by the build system, then just link my
>> application anywhere in the app/ source tree.
>>
>> But how does the code know that it is running on NuttX? There is no
>> CONFIG_NUTTX, there is no OS_managed __NUTTX__ definition.
>>
>> I do see a __NUTTX__ definition defined in some application Makefiles in
>> apps/, but this is a chicken'n'egg problem. They use custom Makefiles to
>> provide these definitions. But what if you want the same application build
>> logic to support either platform. I don't see any way to do that.
>>
>> Has anyone thought of way to do this? Or do you all use custom Makefile
>> for the NuttX build?
>>
>> Greg
>>
>>
Re: I does an app know it is building on NuttX
Posted by James Dougherty <ja...@gmail.com>.
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 <ja...@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 <sp...@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 <ja...@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 <sp...@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 <sp...@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.nathan@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: I does an app know it is building on NuttX
Posted by James Dougherty <ja...@gmail.com>.
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 <sp...@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 <ja...@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 <sp...@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 <sp...@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.nathan@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
> > > >>
> > > >
> > >
> >
>
Re: I does an app know it is building on NuttX
Posted by Flavio Castro Alves Filho <fl...@gmail.com>.
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
<sp...@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 <ja...@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 <sp...@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 <sp...@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.nathan@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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.alves@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves
Re: I does an app know it is building on NuttX
Posted by Gregory Nutt <sp...@gmail.com>.
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 <ja...@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 <sp...@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 <sp...@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.nathan@gmail.com
> > >
> > > wrote:
> > >
> > >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
> > >>
> > >
> >
>
Re: I does an app know it is building on NuttX
Posted by James Dougherty <ja...@gmail.com>.
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 <sp...@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 <sp...@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.nathan@gmail.com
> >
> > wrote:
> >
> >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
> >>
> >
>
Re: I does an app know it is building on NuttX
Posted by Gregory Nutt <sp...@gmail.com>.
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 <sp...@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 <ha...@gmail.com>
> wrote:
>
>> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
>>
>
Re: I does an app know it is building on NuttX
Posted by Gregory Nutt <sp...@gmail.com>.
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 <ha...@gmail.com>
wrote:
> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
>
Re: I does an app know it is building on NuttX
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt <sp...@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
Re: I does an app know it is building on NuttX
Posted by Gregory Nutt <sp...@gmail.com>.
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.
My favorite solution, but not one that is easily fielded would be to use
the NuttX buildroot toolchains:
https://bitbucket.org/nuttx/buildroot/src/master/ . These generate a
nuttx-eab-gcc (toolchain not a none-eabi toolchain) and they have several
advantages: (1) they do not use a foreign libc but build directly using
the NuttX libc. So they will never generate libc header file conflicts.
and (1) they define __NUTTX__
The downside is that, as I recall, they don't build the C++ standard
library.
On Tue, Feb 22, 2022 at 12:50 PM Gregory Nutt <sp...@gmail.com> wrote:
> I have been working on an application for the past several months. Now
> want to get it running on NuttX. I don't have much experience porting
> applications to NuttX and have some dumb newbie questions (I mostly worked
> on the other side of the application/OS interface).
>
> If I have an application that builds and runs on Linux and I want to port
> it to NuttX, I would basically just provide the Kconfig files, Make.defs
> files, and Makefiles as expected by the build system, then just link my
> application anywhere in the app/ source tree.
>
> But how does the code know that it is running on NuttX? There is no
> CONFIG_NUTTX, there is no OS_managed __NUTTX__ definition.
>
> I do see a __NUTTX__ definition defined in some application Makefiles in
> apps/, but this is a chicken'n'egg problem. They use custom Makefiles to
> provide these definitions. But what if you want the same application build
> logic to support either platform. I don't see any way to do that.
>
> Has anyone thought of way to do this? Or do you all use custom Makefile
> for the NuttX build?
>
> Greg
>
>