Makefile Improvement Plan

[AlanRosenthal]

Hi Folks, I've been working to improve the NuttX Makefiles over the last few weeks. See my contributions here: https://github.com/apache/incubator-nuttx/pulls?q=is%3Apr+is%3Aclosed+author%3AAlanRosenthal

Now that I'm more familiar with the codebase/Makefiles, I have some higher level thoughts on how to improve the Makefiles. This is a loose plan, but I'd appreciate any feedback / guidance!

Today, the configure and build stages are slightly intermingled. We should create a clear separation. This will both improve developer ergonomics, and will enable faster incremental builds. My proposal is: the configure stage is responsible for:

• Generating the .config file
• Setting up symlinks
• Extracting tar files if required

The build stage is responsible for:

• Generating the nuttx elf
  • Generating the .a files that the nuttx elf requires
    • Generating the .o files that the .a files require
      • Generating the .c/.h files that the .o files require
• Running Post-build commands

The best way to isolate these stages, is to create separate Makefiles for the configure and build stage. For example, instead of the context rule existing in Unix.mk, it will exist in UnixConfigure.mk (or a better named file).

Any changes to the configuration stage, will first require a clean build, to ensure that everything is in the correct state. Any changes to the build stage, will not require the configuration stage to be rerun.

cc @Ouss4 @xiaoxiang781216 @gustavonihei

[Ouss4]

For the config stage, will this combine dirlinks and context with the steps performed in configure.sh?

[AlanRosenthal]

@Ouss4 I'm still debating the best way to do this. Having a shell script do this is starting to make sense to me. It's easy to serialize the steps (first set up the symlinks, then extract the tar files, etc) and is easy to add logic such as "if you're modifying the .config file, ensure everything is cleaned properly"

[AlanRosenthal]

Any thoughts on using python? That would allow us to the same script for both windows and unix

[xiaoxiang781216]

I am fine with python since it's very popular and portable, but need the input from @patacongo .

[Ouss4]

@patacongo in the past refused to use technologies that will require someone else to maintain. Basically, he wanted to avoid situations where parts of the project depend on a tool that only one person knows how to use and that person disappears. I think right now we can have a discussion with the whole community and see if adopting Python is something we want to do. Most importantly, that there are enough people that are able and available to maintain this.