[nuttx] Confusion between APPNAME and PROGNAME

[Sebastien Lorquet [e-mail] [nuttx]]

Hello

I see that some apps, that uses Application,mk, uses APPNAME as the application
name, but the variable PROGNAME is also used.

What is the difference between the two?

For example, in sched_note I understand that APPNAME is the name of the app but
PROGNAME is the name of the generated binary file for app builds.

On the contrary examples/wget only defines PROGNAME but no APPNAME

Is that an error? How to deal with it? Change every makefile that references
Application.mk, or, in the same file, define APPNAME=PROGNAME if APPNAME is not
defined?

My ideal view is:

- all makefiles shall define APPNAME

- Application.mk computes PROGNAME if it is not already defined in individual
makefiles.

What do you think?

[Sebastien Lorquet [e-mail] [nuttx]]

The following makefiles use Application.mk but did not define APPNAME, which
probably does Bad Things since APPNAME is used for app registration, for example:

modified: examples/configdata/Makefile
modified: examples/hidkbd/Makefile
modified: examples/mm/Makefile
modified: examples/mount/Makefile
modified: examples/mtdpart/Makefile
modified: examples/mtdrwb/Makefile
modified: examples/nsh/Makefile
modified: examples/nxffs/Makefile
modified: examples/pashello/Makefile
modified: examples/pipe/Makefile
modified: examples/rgmp/Makefile
modified: examples/sendmail/Makefile
modified: examples/serloop/Makefile
modified: examples/smart/Makefile
modified: examples/uavcan/Makefile
modified: examples/wget/Makefile

I added the definitions to these files. Do you want a patch?

I also developed a way to automatically create a link from apps/include/APPNAME
to SUBDIR/APPNAME/export. This is very useful for libraries that publish headers
usable by other apps.

Now an app is not split in two places anymore, everything related to "libacme"
is in examples/libacme/*, instead of BOTH examples/libacme/* and
include/libacme. This is also very useful for custom apps/libraries.

The link is set up during the depend target if the application folder contains a
dir called "export", and teared down during distclean.

It only uses make syntax and the provided (un)link[.sh|.bat] tools.

NOTE: I will probably soon provide an alternative to Kmenu files, a MENU=thing
in Makefiles that use Directory.mk seems FAR more practical. I should have done
that before.

Sebastien

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Hello
I see that some apps, that uses Application,mk, uses APPNAME as the application
name, but the variable PROGNAME is also used.
What is the difference between the two?
For example, in sched_note I understand that APPNAME is the name of the app but
PROGNAME is the name of the generated binary file for app builds.
On the contrary examples/wget only defines PROGNAME but no APPNAME
Is that an error? How to deal with it? Change every makefile that references
Application.mk, or, in the same file, define APPNAME=PROGNAME if APPNAME is not
defined?
- all makefiles shall define APPNAME
- Application.mk computes PROGNAME if it is not already defined in individual
makefiles.
What do you think?
--
Sébastien Lorquet

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The following makefiles use Application.mk but did not define APPNAME, which
modified: examples/configdata/Makefile
modified: examples/hidkbd/Makefile
modified: examples/mm/Makefile
modified: examples/mount/Makefile
modified: examples/mtdpart/Makefile
modified: examples/mtdrwb/Makefile
modified: examples/nsh/Makefile
modified: examples/nxffs/Makefile
modified: examples/pashello/Makefile
modified: examples/pipe/Makefile
modified: examples/rgmp/Makefile
modified: examples/sendmail/Makefile
modified: examples/serloop/Makefile
modified: examples/smart/Makefile
modified: examples/uavcan/Makefile
modified: examples/wget/Makefile
I added the definitions to these files. Do you want a patch?

Sure!

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
I also developed a way to automatically create a link from apps/include/APPNAME
to SUBDIR/APPNAME/export. This is very useful for libraries that publish headers
usable by other apps.

I am not so enthusiastic about that change but I understand your point.

I also do not think that it will work with Windows. In windows, you cannot use symbolic links. So, as a fallback, it copies whole directories. This has several consequences one of which is that order now matters: The link to nuttx/includes/apps is created very early in the build... before anything else. On Windows, these links are really directory copies.

So any subsequent directory copies into apps/include will not have effect.

No, I don't want this change.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The link is set up during the depend target if the application folder contains a
dir called "export", and teared down during distclean.

Too late.

Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello,

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The following makefiles use Application.mk but did not define APPNAME, which
modified: examples/configdata/Makefile
modified: examples/hidkbd/Makefile
modified: examples/mm/Makefile
modified: examples/mount/Makefile
modified: examples/mtdpart/Makefile
modified: examples/mtdrwb/Makefile
modified: examples/nsh/Makefile
modified: examples/nxffs/Makefile
modified: examples/pashello/Makefile
modified: examples/pipe/Makefile
modified: examples/rgmp/Makefile
modified: examples/sendmail/Makefile
modified: examples/serloop/Makefile
modified: examples/smart/Makefile
modified: examples/uavcan/Makefile
modified: examples/wget/Makefile
I added the definitions to these files. Do you want a patch?

Sure!

See the attached patch.

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
I also developed a way to automatically create a link from apps/include/APPNAME
to SUBDIR/APPNAME/export. This is very useful for libraries that publish headers
usable by other apps.

I am not so enthusiastic about that change but I understand your point.
I also do not think that it will work with Windows. In windows, you cannot use
symbolic links. So, as a fallback, it copies whole directories. This has several
consequences one of which is that order now matters: The link to
nuttx/includes/apps is created very early in the build... before anything else.
On Windows, these links are really directory copies.

It is the same issue than with other symbolic links, like arch, chip, board....
The goal is to make these files available to apps that depend on the lib. The
developer has to know what she does when she uses windows. But for everyone else
(windows users and linux users/developers), it works as intended.

But okay. I understand that you dont want yet another set of fake links that are
not absolutely required to make the build work.

I will keep this change for me.

Post by ***@yahoo.com [nuttx]
So any subsequent directory copies into apps/include will not have effect.
No, I don't want this change.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The link is set up during the depend target if the application folder contains a
dir called "export", and teared down during distclean.

Too late.

I am not sure to understand what that means. Because you said "no" the line
before? :) Or do you mean that depend is not the right place to do that?

Post by ***@yahoo.com [nuttx]
Greg

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The link is set up during the depend target if the application folder contains a
dir called "export", and teared down during distclean.

Too late.

I am not sure to understand what that means. Because you said "no" the line
before? :) Or do you mean that depend is not the right place to do that?

The depend target is "too late" in the build sequence to do what you want to do. By then the nuttx/include/apps directory copy has already been performed (on Windows) and any further modifications that you make to apps/include will have no effect.

If you really want to solve this in a general way, I think that the way to do this would be:

1. Remove the nuttx/include/apps link altogether. It should not be referenced by the anything the nuttx/ directory anyway (it if is, that would not be good).

2. Change all occurrences of

#include <apps/bla/bla>

to

#include "bla/bla"

And add -I apps/include to the CFLAGS in apps/Makefile.

Even more generally.. If you want to have private include directories in applications, you could also simply add the paths those directories to the CFLAGS in apps/Makefile without using any symbolic links.

I like the idea of removing nuttx/include/apps. NuttX should get out and stay out of the application business.

Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
The link is set up during the depend target if the application folder contains a
dir called "export", and teared down during distclean.

Too late.

I am not sure to understand what that means. Because you said "no" the line
before? :) Or do you mean that depend is not the right place to do that?

The depend target is "too late" in the build sequence to do what you want to do.
By then the nuttx/include/apps directory copy has already been performed (on
Windows) and any further modifications that you make to apps/include will have
no effect.
If you really want to solve this in a general way, I think that the way to do
1. Remove the nuttx/include/apps link altogether. It should not be referenced by
the anything the nuttx/ directory anyway (it if is, that would not be good).
2. Change all occurrences of
#include <apps/bla/bla>
to
#include "bla/bla"
And add -I apps/include to the CFLAGS in apps/Makefile.

I like this change, for more reasons that my intended change. This is a good
thing, since as you said nuttx does not need to know about the apps at all.

Also, why change <> includes to "" includes?

Post by ***@yahoo.com [nuttx]
Even more generally.. If you want to have private include directories in
applications, you could also simply add the paths those directories to the
CFLAGS in apps/Makefile without using any symbolic links.

Yes, this is really not an issue. But my goal was public includes instead.

Post by ***@yahoo.com [nuttx]
I like the idea of removing nuttx/include/apps. NuttX should get out and stay
out of the application business.

On it. Silversurfer says there are some occurrences :

***@nuc:~/mynut/apps$ ag '#include <apps/' | wc -l
520

But also, this :

***@nuc:~/mynut/nuttx$ ag '#include <apps/' | wc -l
6

Here are the culprits:

tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");

configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>

configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>

configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>

configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>

binfmt/pcode.c
50:#include <apps/prun.h>

Do you have any about how to deal with these?

Sebastien

Post by ***@yahoo.com [nuttx]
Greg

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by ***@yahoo.com [nuttx]
If you really want to solve this in a general way, I think that the way to do
1. Remove the nuttx/include/apps link altogether. It should not be referenced by
the anything the nuttx/ directory anyway (it if is, that would not be good).
2. Change all occurrences of
#include <apps/bla/bla>
to
#include "bla/bla"
And add -I apps/include to the CFLAGS in apps/Makefile.

I like this change, for more reasons that my intended change. This is a good
thing, since as you said nuttx does not need to know about the apps at all.
Also, why change <> includes to "" includes?

Because I suggest -I, they would not longer by system includes. System includes and application includes have different PATH variables. System includes are defined with -isystem or -I-, application includes are set up with -I.

These have always logically been application includes but were in an include directory added to the system include path (with -isystem) so they needed <>. "" would be more appropriate, especially after such a change.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by ***@yahoo.com [nuttx]
I like the idea of removing nuttx/include/apps. NuttX should get out and stay
out of the application business.

520

6

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>
binfmt/pcode.c
50:#include <apps/prun.h>
Do you have any about how to deal with these?

Some cases I understand, some I do not. The prun problem in is the TODO list.

The general answer for the configs/ issues is that board-specific application logic belongs in apps/platform/<board>

nuttx/configs/<board>: OS-internal board specific logic
apps/platform/<board>: Board-specific application logic

Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello,

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by ***@yahoo.com [nuttx]
If you really want to solve this in a general way, I think that the way to do
1. Remove the nuttx/include/apps link altogether. It should not be referenced by
the anything the nuttx/ directory anyway (it if is, that would not be good).
2. Change all occurrences of
#include <apps/bla/bla>
to
#include "bla/bla"
And add -I apps/include to the CFLAGS in apps/Makefile.

I like this change, for more reasons that my intended change. This is a good
thing, since as you said nuttx does not need to know about the apps at all.
Also, why change <> includes to "" includes?

Because I suggest -I, they would not longer by system includes. System includes
and application includes have different PATH variables. System includes are
defined with -isystem or -I-, application includes are set up with -I.
These have always logically been application includes but were in an include
directory added to the system include path (with -isystem) so they needed <>. ""
would be more appropriate, especially after such a change.

Okay, I'm fine with that. I have started to change flash_eraseall, which is
enabled in my current config.

I will first change all required app includes and makefiles. Then we will deal
with bogus app/ includes in the nuttx repo.

Do you plan to merge my two previous patches soon so I can cleanup my working
copies?

Thanks

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by ***@yahoo.com [nuttx]
I like the idea of removing nuttx/include/apps. NuttX should get out and stay
out of the application business.

520

6

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>
binfmt/pcode.c
50:#include <apps/prun.h>
Do you have any about how to deal with these?

Some cases I understand, some I do not. The prun problem in is the TODO list.
The general answer for the configs/ issues is that board-specific application
logic belongs in apps/platform/<board>
nuttx/configs/<board>: OS-internal board specific logic
apps/platform/<board>: Board-specific application logic
Greg

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Do you plan to merge my two previous patches soon so I can cleanup my working

copies?


I think everything is merged.. let me know if I missed something.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>
binfmt/pcode.c
50:#include <apps/prun.h>
Do you have any about how to deal with these?

I have got to run an errand now, I will try to resolve these this afternoon.

Greg

[[e-mail] [nuttx]]

Hi, Sebastien,

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>
binfmt/pcode.c
50:#include <apps/prun.h>
Do you have any about how to deal with these?

I have address all of the inclusions of files from include/apps in the nuttx/ repository. There are no longer any such inclusions!


So you can continue with your plan to remove the include/apps link. That should be easily doable now.


Greg

[Sebastien Lorquet [e-mail] [nuttx]]

This is great news! Thank you for this!

The next big step is to change all #include <apps/blah/blah.h> to "blah/blah.h"

But before that I will rename some local apps headers that have the same name as
the ones in apps/include.

This happens at least for ftpc, IIRC.

Sebastien

Post by ***@yahoo.com [nuttx]
Hi, Sebastien,

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>
binfmt/pcode.c
50:#include <apps/prun.h>
Do you have any about how to deal with these?

**//___^
I have address all of the inclusions of files from include/apps in the nuttx/
repository. There are no longer any such inclusions!
So you can continue with your plan to remove the include/apps link. That should
be easily doable now.
Greg

[[e-mail] [nuttx]]

That is an argument for using #include <file> instead of #include "file". You should not have change file names. Instead let the include path distinguish the files. We don't have to introduce ugly file names.

[Sebastien Lorquet [e-mail] [nuttx]]

Not sure ...

***@nuc:~/mynut/apps$ ls include/
builtin.h fsutils libcanopen nsh.h prun.h tiff.h
canutils ftpc.h modbus nxplayer.h readline.h zmodem.h
cle.h gpsutils netutils platform symtab.h

-> that was <apps/ftpc.h> and will become "ftpc.h" (or <ftpc.h>)

***@nuc:~/mynut/apps$ ls examples/ftpc/
ftpc_cmds.c ftpc.h ftpc_main.c Kconfig Make.defs Makefile

-> that is already "ftpc.h"

A proposal is to rename the local "ftpc.h" to "ftpc_private.h"

Is the system path feature enough to distinguish <ftpc.h> and "ftpc.h" ?

Or, we can move include/ftpc.h to include/netutils/ftpc.h since we already have
ftpd.h in there:

***@nuc:~/mynut/apps$ ls include/netutils/
base64.h dhcpd.h httpd.h ntpclient.h tftp.h xmlrpc.h
chat.h discover.h ipmsfilter.h pppd.h thttpd.h
cJSON.h esp8266.h md5.h smtp.h urldecode.h
dhcpc.h ftpd.h netlib.h telnetd.h webclient.h

This will move the "common" include out of the way, and for consistency, I think
that this option is the best.

Sebastien

That is an argument for using #include <file> instead of #include "file". You
should not have change file names. Instead let the include path distinguish the
files. We don't have to introduce ugly file names.

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Not sure ...
builtin.h fsutils libcanopen nsh.h prun.h tiff.h
canutils ftpc.h modbus nxplayer.h readline.h zmodem.h
cle.h gpsutils netutils platform symtab.h
-> that was <apps/ftpc.h> and will become "ftpc.h" (or <ftpc.h>)
ftpc_cmds.c ftpc.h ftpc_main.c Kconfig Make.defs Makefile
-> that is already "ftpc.h"
A proposal is to rename the local "ftpc.h" to "ftpc_private.h"

Yech. That is an awful name, well at least compared to just ftpc.h. Last year I just finished changing all of the xyz_internal.h header files in configs to avoid that kind of naming.

Here is a counter proposal: Move apps/include/ftpc.h to apps/include/netutils/ftpc.h where is belongs. The one will be included like

#include <netutils/ftpc.h>

and the other as

#include "ftpc.h"

Those can never be confused.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Is the system path feature enough to distinguish <ftpc.h> and "ftpc.h" ?

Yes, it should be:

https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

If your CFLAGS contain "-I . -I- $(APPSDIR)/include" (-I- is the same as -isystem, -I- is deprecated). Then the search path for #include "ftpc.h" will be '.' then $(APPSDIR)/include in that order. For #include <ftpc.h> the search path will only be $(APPSDIR)/include

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Or, we can move include/ftpc.h to include/netutils/ftpc.h since we already have

Yes, we are thinking along the same lines. I am going to make that change. I am think that it would be good to have all header files in directories mirroring the apps/layout. system/, canutils/, netutils/, etc.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
base64.h dhcpd.h httpd.h ntpclient.h tftp.h xmlrpc.h
chat.h discover.h ipmsfilter.h pppd.h thttpd.h
cJSON.h esp8266.h md5.h smtp.h urldecode.h
dhcpc.h ftpd.h netlib.h telnetd.h webclient.h
This will move the "common" include out of the way, and for consistency, I think
that this option is the best.

Agreed. I will move some files in apps/include today.

Greg

[[e-mail] [nuttx]]

... I am think that it would be good to have all header files in directories mirroring the apps/layout. system/, canutils/, netutils/, etc.

Done! Committed and pushed. There are no longer any header files in the top-level apps/include directory. They are now all in subdirectories matching the apps/ directory name.


Greg

[[e-mail] [nuttx]]

Greg,

wow 26 posts...


Will you please wiki the correct usage for including headers now for apps, and when you want to see "xxxx.h" and <xxxx.h> used?


David

[Sebastien Lorquet [e-mail] [nuttx]]

Excellent, thanks.

I will do the renames in all apps, with the changes in the Makefiles. Probably
not before Monday, since I'm touring Normandy this week end with $WIFE and
$DAUGHTER...

Sebastien

... I am think that it would be good to have all header files in directories

mirroring the apps/layout. system/, canutils/, netutils/, etc.
Done! Committed and pushed. There are no longer any header files in the
top-level apps/include directory. They are now all in subdirectories matching
the apps/ directory name.
Greg

[[e-mail] [nuttx]]

Sebastien,


Wow They are variables? I could understand constants :)


David

[Sebastien Lorquet [e-mail] [nuttx]]

hahaha :)

I was thinking template substitutions... These cant be changed once they are
defined, right? ;-)

Sebastien

Post by ***@yahoo.com [nuttx]
Sebastien,
Wow They are variables? I could understand constants :)
David

[Sebastien Lorquet [e-mail] [nuttx]]

Here is a "Pokemon patch" to change all includes in apps, including makefiles
that still dont include Application.mk . I think I caught them all, but...
you're never sure.

Associated is a patch on the nuttx repo to remove the include/apps dirlink.

No error will show up until you apply the second (nuttx) patch... then apps
might break because they cant find their includes.

I am very happy with this change, since your vision is that apps are not NuttX,
this greatly improves the apps-NuttX separation, apps includes nuttx, but not
the reverse.

Please, review this patch and become comfortable with it before applying it to
master. I would be sad if I break lots of things because of a small mistake. A
full configurations tests is probably wise.

Sebastien

(No, I have played ingress, but no pokemon.)

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
hahaha :)
I was thinking template substitutions... These cant be changed once they are
defined, right? ;-)
Sebastien

Post by ***@yahoo.com [nuttx]
Sebastien,
Wow They are variables? I could understand constants :)
David

[[e-mail] [nuttx]]

Well, if you want to make an omelet you have to break a few eggs.


I will apply the patches and run some exhaustive build tests. In order to use my micro "build farm" I will need to commit to master so there is a possibility of some breakage today. That will hopefully be fixed by tomorrow.


Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello,

To do that without breaking master, you could keep an "integration" branch to
push third party patches, your build farm could be set up to pull this
integration branch instead of master.

When build is ok, you can merge the integration branch in master.

Thank you for your tests.

Sébastien Lorquet

Post by ***@yahoo.com [nuttx]
Well, if you want to make an omelet you have to break a few eggs.
I will apply the patches and run some exhaustive build tests. In order to use
my micro "build farm" I will need to commit to master so there is a possibility
of some breakage today. That will hopefully be fixed by tomorrow.
Greg

[[e-mail] [nuttx]]

Committed! I did one thing differently however. Your patch modified every Makefile and added:


CFLAGS += -I$(APPDIR)/include


There are a few problems here:


1. -I is a GCC only command line option. Other compilers may emulate GCC and use that option as well, but there are most certainly compilers supported by NuttX that do not understand -I.


The canonically correct way to do this is by using tools/incdir.sh or incdir.bat. Those scripts are smart enough to create the correct command line argument for all all supported compilers.


2. the / delimiter will only work on Linux or on Cygwin if you have a custom tool chain built under Cygwin. it will not work with the standard Windows tools from ARM/mbed, CodeSourcery, Atollic or any of the others. Those tools only understand backslash delimiters.


Using $(DELIM) will fix that issue.


3. This would break all of the NxWidgets Makefiles under Unittests. Those would have to be modified.too!


I fixed that by verifying that $(APPSDIR)/Make.defs is included by Application.mk and by every Makefile. The I put the modification of the CFLAGS there. That means that I did not have to modify any of the Makefiles and it still seems to work okay.


But the big test if just starting now. Takes 3-4 hours then we will know for certain if we have reason to be confident.


Thanks,
Greg

[[e-mail] [nuttx]]

One thing that I don't want to do is to break the NxWidgets package. This gets installed into the apps/ directory using the symbolic link external/. The magic external symbolic link can be used to automatically include any external application into the repository (maybe external is all you really need?).


Anyway, it also includes header files from apps/include:


$ grep -r include NxWidgets/* | grep apps/
NxWidgets/nxwm/src/ccalibration.cxx:# include <apps/platform/configdata.h>
NxWidgets/nxwm/src/cmediaplayer.cxx:#include <apps/system/nxplayer.h>
NxWidgets/nxwm/src/cnxterm.cxx:#include <apps/nshlib/nshlib.h>
NxWidgets/UnitTests/nxwm/nxwm_main.cxx:# include <apps/platform/configdata.h>


The Makefiles for the NxWdigets tests are at NxWidgets/Unittests/<testname>/Makefile. These have not been updated in a long time and have diverged from the changes made to the corresponding Makefiles under apps/. I have been making a few necessary changes as I go (such as adding the preconfig: target).


If there are changes made to the apps/ include path, those changes will need to be made in NxWidgets and all of those Makefiles under Unittests as well or many builds will be broken.


Greg

[[e-mail] [nuttx]]

You have read this, right? http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications

[[e-mail] [nuttx]]

Yes.

I am referring to the ramification from the current changes being made. More about the new structure and how it should be used correctly.

[Sebastien Lorquet [e-mail] [nuttx]]

We should extend this to explain that more Kconfigs are automatically generated.

Now you just have to ( clone a repo / extract a zip with a subdir ) containing a
Kconfig/Makefile/Make.defs in any apps/ subdirectory and it will be available in
Kconfig, then you just have to select it before building.

Then, more doc will be required to describe what we're about to do with
inclusions, because customized "libapps" will want to export header files for
other customized apps...

Sebastien

Post by ***@yahoo.com [nuttx]
You have read this, right?
http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");

This one is not a problem. mkfsdata.pl really belongs in apps/tools and probably should be moved there some day. But it is not a problem in regard to the current discussion.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>

This one was easily fixed by just removed the bogus inclusion.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>

The above two are special cases. These are application main functions architecturally similar to the main functions in apps/examples/ or apps/system, but with a difference: They are boot loaders.

I occasionally write very low level boot loader applications. These low level boot loaders differ from other applications in that they need extensive access to OS internals and supervisor mode access. They are really kernel threads!

So they have to stay in configs/sama5d4-ek. They cannot be moved into apps/platform.

I think that the solution would be to move the hex2bin library out of apps/system/hex2bin and into nuttx/libc/hex2bin. The hex2bin task would still reside in apps/system/hex2bin, but the shareable logic would need to be in libc.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>

This one would take some re-architecting to finish: Basically the problem is that:

1. system/zoneinfo downloads the time zone database and converts it to a ROMFS file system in that directory. This kind of useless since the OS is where the ROMFS data belongs, but several applications do that.
2. apps/include/zoneinfo.h contains the external data declarations needed by sim_zoneinfo.c to mount the zoneinfo ROMFS file system.

It seems to me that the solution would be to:

- Move the zoneinfo ROMFS database somewhere under nuttx/. Not sure where yet, perhaps nuttx/libc/time/?
- Move the ROMFS external declarations to nuttx/include/zoneinfo.h

But that would take some effort.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
binfmt/pcode.c
50:#include <apps/prun.h>

This is described in the TODO list. It is an issue. I suppose that only solution is, as with hex2bin.h, to move the Pascal Run-time library (prun) into nuttx/libc.

Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello

I am in the process of converting <apps/blah/blah.h> to "blah/blah.h"

This is tedious and leads to duplicates.

So I had to change quite a few "local" headers whose name was similar to include
files in apps/include. I renamed them to blah_private.h when needed.

I am still not comfortable with using double quotes: In linux, when you install
a lib in the system, the includes go to /usr/include/blah/blah.h and you include
them as <blah/blah.h>, making it apparent that this include is from the system
and not from the project (app)

But I can live with that if you believe it's the correct decision. As some
people say, on a scale from I dont care to WTF ITS this is a two. [1] :)

[1] http://www.cs.cmu.edu/~tom7/mario/mario.pdf

Sebastien

I have looked at all of these and fixed the easy one. Here is the scoop on each

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
tools/mkfsdata.pl
44:print(OUTPUT "#include <apps/netutils/httpd.h>\n\n");

This one is not a problem. mkfsdata.pl really belongs in apps/tools and probably
should be moved there some day. But it is not a problem in regard to the current
discussion.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
configs/cc3200-launchpad/src/cc3200_boot.c
51:#include <apps/nsh.h>

This one was easily fixed by just removed the bogus inclusion.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
configs/sama5d4-ek/src/at25_main.c
53:#include <apps/hex2bin.h>
configs/sama5d4-ek/src/dram_main.c
46:#include <apps/hex2bin.h>

The above two are special cases. These are application main functions
architecturally similar to the main functions in apps/examples/ or apps/system,
but with a difference: They are boot loaders.
I occasionally write very low level boot loader applications. These low level
boot loaders differ from other applications in that they need extensive access
to OS internals and supervisor mode access. They are really kernel threads!
So they have to stay in configs/sama5d4-ek. They cannot be moved into apps/platform.
I think that the solution would be to move the hex2bin library out of
apps/system/hex2bin and into nuttx/libc/hex2bin. The hex2bin task would still
reside in apps/system/hex2bin, but the shareable logic would need to be in libc.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
configs/sim/src/sim_zoneinfo.c
48:#include <apps/zoneinfo.h>

1. system/zoneinfo downloads the time zone database and converts it to a ROMFS
file system in that directory. This kind of useless since the OS is where the
ROMFS data belongs, but several applications do that.
2. apps/include/zoneinfo.h contains the external data declarations needed by
sim_zoneinfo.c to mount the zoneinfo ROMFS file system.
- Move the zoneinfo ROMFS database somewhere under nuttx/. Not sure where yet,
perhaps nuttx/libc/time/?
- Move the ROMFS external declarations to nuttx/include/zoneinfo.h
But that would take some effort.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
binfmt/pcode.c
50:#include <apps/prun.h>

This is described in the TODO list. It is an issue. I suppose that only solution
is, as with hex2bin.h, to move the Pascal Run-time library (prun) into nuttx/libc.
Greg

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
I am still not comfortable with using double quotes: In linux, when you install

a lib in the system, the includes go to /usr/include/blah/blah.h and you include
them as <blah/blah.h>, making it apparent that this include is from the system
and not from the project (app)

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
But I can live with that if you believe it's the correct decision. As some

people say, on a scale from I dont care to WTF ITS this is a two. [1] :)

It has about the same priority to me as well. If you install the header files in the system header file directories, then <> is appropriate. Otherwise, "" is probably more appropriate.

But you can proclaim that apps/include is a system header file directory then <> is more appropriate.

Not really work arguing about.

The remaining issues with inclusions from nuttx/ have not been resolved. So are difficult and will take some time. So it will be some time before this can be merged into master.

Greg

[[e-mail] [nuttx]]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
I see that some apps, that uses Application,mk, uses APPNAME as the application
name, but the variable PROGNAME is also used.
What is the difference between the two?

Good question. So good that I answered it with a Wiki page: http://www.nuttx.org/doku.php?id=wiki:nshhowtos:appname-vs-progname

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
For example, in sched_note I understand that APPNAME is the name of the app but
PROGNAME is the name of the generated binary file for app builds.
On the contrary examples/wget only defines PROGNAME but no APPNAME
Is that an error? How to deal with it? Change every makefile that references
Application.mk, or, in the same file, define APPNAME=PROGNAME if APPNAME is not
defined?
- all makefiles shall define APPNAME
- Application.mk computes PROGNAME if it is not already defined in individual
makefiles.
What do you think?

I agree. If it includes Appliction.mk and does not define APPNAME, then I assume it is an error. Even if it does not, consistency is a good thing.

When you have to manage a large body of code it is absolutely essential that everything be done in the same way. It is impossible to the job if everyone generates every piece of code in their own, special, individual way. Even if that way is better, it makes the overall job impossible. That is why I am strict about how things are done: Because once it is committe, I have to maintain it and I can't do that if it is too original.

Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello again,

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
I see that some apps, that uses Application,mk, uses APPNAME as the application
name, but the variable PROGNAME is also used.
What is the difference between the two?

http://www.nuttx.org/doku.php?id=wiki:nshhowtos:appname-vs-progname

ooops... I skipped that. But I got it right anyway :)

Post by ***@yahoo.com [nuttx]

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
For example, in sched_note I understand that APPNAME is the name of the app but
PROGNAME is the name of the generated binary file for app builds.
On the contrary examples/wget only defines PROGNAME but no APPNAME
Is that an error? How to deal with it? Change every makefile that references
Application.mk, or, in the same file, define APPNAME=PROGNAME if APPNAME is not
defined?
- all makefiles shall define APPNAME
- Application.mk computes PROGNAME if it is not already defined in individual
makefiles.
What do you think?

I agree. If it includes Appliction.mk and does not define APPNAME, then I assume
it is an error. Even if it does not, consistency is a good thing.
When you have to manage a large body of code it is absolutely essential that
everything be done in the same way. It is impossible to the job if everyone
generates every piece of code in their own, special, individual way. Even if
that way is better, it makes the overall job impossible. That is why I am strict
about how things are done: Because once it is committe, I have to maintain it
and I can't do that if it is too original.

I understand.

This probably implies that other app folders should/will be converted to
Application.mk in the future, I guess.

BTW, Please have a look at the attached patch to avoid the Kmenu files.
The patch does not delete these files, it only includes correct values in makefiles.

Use if you like it.

Sebastien

Post by ***@yahoo.com [nuttx]
Greg

[[e-mail] [nuttx]]

Seems simpler.


If I include this change, then I should also remove all of the existing Kmenu files, right?


Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Exactly. That's the goal. These deletions should have been in the diff but I
messed up my git diff.

Sebastien.

Post by ***@yahoo.com [nuttx]
Seems simpler.
If I include this change, then I should also remove all of the existing Kmenu files, right?
Greg

[[e-mail] [nuttx]]

Okay... the patch has been committed and the Kmenu files have been removed.


Greg

[Sebastien Lorquet [e-mail] [nuttx]]

what about the APPNAMEs additions in example/*/Makefile ?

Attached again in case you missed it.

Sebastien

Post by ***@yahoo.com [nuttx]
Okay... the patch has been committed and the Kmenu files have been removed.
Greg

[[e-mail] [nuttx]]

Yeah, I missed that one. It is now committed too.


Greg