Closed protobits closed 1 year ago
This is the problematic line: https://github.com/apache/incubator-nuttx-apps/blob/f3828ccbca3e45319d804cd5c3f91a4764de68c8/Application.mk#L185
Good finding @v01d ! Is this multiple buitin applications feature documented in some place?
Not really, it would be good to have a section in the docs explaining how to write an app (maybe under "applications").
A workaround is to not use main
to define the entry point, the <progname>_main
and thus not rely on this feature.
Well, in the past it was appxyz_main(), move to main() was an improvement. Maybe we can fix it without returning to the previous way to do it.
I don't really have a better proposal and don't really like the added complexity of the solution, so I will just leave this issue open in case someone thinks of a better approach. I mentioned the workaround in case someone bumps into the problem. I wasn't proposing we adopt it for existing apps, since it would be going backwards as you mention.
Instead of finding the index of the string, you could zip the two lists together (https://riptutorial.com/makefile/example/23643/zipping-lists), and then eval a template (https://www.gnu.org/software/make/manual/html_node/Eval-Function.html) for each pair.
Yes, this is the right approach to fix this problem I discussed internally with @anchao .
Yes, this is the right approach to fix this problem I discussed internally with @anchao .
@anchao has fixed this incremental compilation issue in this excellent work https://github.com/apache/nuttx-apps/pull/1603, but there is also a potential risk:
[!IMPORTANT] If an application has MAINSRCS with the same name in different directories, function
GETENTRYINDEX
will have wrong results becausenotdir
is used.
I plan to establish a mapping relationship between progname and src during defining variables.
An application
Make.defs
can define multiple builtin applications by using something like:When building
a.c
the-Dmain=a_main
will be defined, and similarly forb.c
. However, the logic inApplication.mk
simply iteratesPROGNAME
in order to build eachmain
definition. This assumes that all targets will be built. When only one of these is built (as part of a previous build), it will mismatch the corresponding program name (it will go in order from firstPROGNAME
entry).The correct solution would be to find the index of the C file in
MAINCSRCS
and get the corresponding entry inPROGNAME
. Make does not implement such a function and there's some trickery to do so: https://stackoverflow.com/questions/9674711/makefile-find-a-position-of-word-in-a-variableAs the
Application.mk
file is already really convoluted I don't want to keep making this worse.Any better ideas?
This of course would be much easier if we just used the
.c
file name as PROGNAME but that would be a breaking change for apps using a different name.