> > Yes, there has to be a Make.defs file in the top level. One person on the list has suggested eliminating the Make.defs file and incorporating the Make information in the .config file. Then the Make.defs file would have to be auto-generated at configuration time too.
> I can agree with that idea. Even without the Kconfig feature, the 187
> Make.defs files are all nearly identical. Most of the definitions, like
> CC CXX CPP LD AR NM OBJCOPY OBJDUMP CFLAGS CXXFLAGS CXXPICFLAGS
> CPPFLAGS AFLAGS OBJEXT LIBEXT EXEEXT PREPROCESS COMPILE COMPILEXX
> ASSEMBLE ARCHIVE CLEAN HOSTCC HOSTINCLUDES HOSTCFLAGS HOSTLDFLAGS
> are exactly the same in most cases. It looks like you could make a
> single, global Make.defs containing the standard definitions, and then
> include at the bottom of that file a project-specific hook to allow
> redefining for the special cases.
Well, certainly that have to be different for each different processor and for each supported toolchain.
> One benefit of this change would be a large refactoring of duplicated
> code, but the real reason why I mention this is because I wanted to
> add a verbose build mode (like Linux make V=1) that would show the
> commands being executed. This really helps when debugging build issues
> (like the Kconfig stuff).
> I started to refactor this stuff across the whole nuttx tree, but I
> gave it up because I wasn't sure how you would like it. Big
> refactoring can be painful, since things can break in surprising ways.
I agree with you in principle. Duplicated code is nothing to be proud of but neither does it bother me so much. Duplicated code can be a maintenance issue, but otherwise I don't see any problem. Duplication is sometimes the cleanest way to simplify difficult problems and to avoid strong coupling. The worst spaghetti code sometimes evolves from well-intended people who are just trying to avoid duplication of logic.
The problem with consolidating the .config and Make.defs file into one file is also a logistic nightmare as you have noticed. And I cannot risk wholesale breakage of board configurations.
My original intent with the format of the .config file is that it would have a syntax that can be included both by Makefiles and by Bash scripts. The beauty of that is that the same definitions can be used to control the make as well as the scripts (as well as C/C++ files via the derived config.h file).
So another minor concern issue is adding some of the definitions needed by Make.defs could break the usage of the .config file by scripts. I have to say that this is only a minor concern because some additions in the defconfig files have already broken that anyway: I used some parenthesis and '|', and "<<" operators in the defconfig files and those cause syntax errors when included in the Bash scripts.
> > I think that the normal usage model would be:
> > 1. Pick a starting configuration, let's say configs/myboard/nsh. This is not very different from working with Linux. There are (or were last time I looked) a set of defconfig files in the Linux source try. When you start a new configuration, you would not start from scratch but, instead, copy the Linux defconfig file to the Linux top directory and 'make menuconfig'
> Just for the record, the Linux Kbuild system does indeed let you start
> from scratch, and it produces a working configuration. People often
> start with 'make defconfig', but you can and I often do start from
> An important feature of Kbuild is that you can save your .config on
> the side. It contains everything you need to reproduce your build
> With nuttx kbuild in its current state, the .config produced by
> menuconfig is not worth very much, since it is not self contained.
Its been awhile since I have worked with Linux, but my recollection is that most of the Make definitions such as those are not contained in the .config file either. There are hard-coded in various Makefiles in the source tree. NuttX is not really very different other in that sense.
You should be able to create the NuttX .config file from scratch too, but it would need the Make fragaments in addition right now.
> The system can or should (one day) work like this:
> 1. create a .config with the options you want
> 2. build and test the image
> 3. save the .config, send it to a friend
> 4. he copies the .config to his nuttx root
> 5. he does make oldconfig
> 6. build, run, enjoy
> So, that is perhaps a goal to work toward. Right now I see there are
> other issues to fix, one step at a time...
I agree. Assuming that you already have the BSP support in place. Then there are three pieces that you need now to build a system (assuming that we can exclude the appconfig file). These are:
1) .config file which is unique to one board configuration. I see this as enabling and disabling the features that define the configuration.
2) The Make.defs file which is unique to the MCU and toolchain. The same Make.defs file could by used by multiple board configurations. This piece could be included in the .config file as you suggest, but it would be a difficult step to get to that.
3) The linker script which is normally called ld.script. This can very with each board and each memory configuration. The LPC43, for example, might run our of external NOR, NAND, or SPI FLASH, or from internal SRAM. A different linker script is needed for each memory configruation. For most boards, however, the memory configuration is fixed for all configurations.
I have been addressing the duplication of linker scripts by creating a directory called 'scripts', one for each board. There I can consolidate the board-specific linker scripts in one place with no duplication. This is not a problem because each Make.defs file uniquely points to the linker script to be used.
$ ls -d1 */scripts
A similar thing could also be done with Make.defs files to reduce duplication.
> > 2. So I think, by analogy, the next thing would be:
> > cd tools
> > ./configure.sh myboard/nsh
> > There is a problem with this right now: the configure.sh script will expect to find an appconfig file. So you can't really use the existing configure.sh script. You will probably have to copy defconfig and Make.defs file for now.
> > 3. Then set up the new configuration:
> > make menuconfig
> > 4. And, if you like the configuration, save it:
> > cp .config configs/myboard/defconfig
> But what about configs/myboard/appconfig?
> Isn't the Kconfig .config supposed to replace both of these?
When you use the automatic configuration, you do not need an appconfig file. This is because:
1) When you use the automated configuration tool, you will always get this definition in the .config file:
This comes from nuttx/Kconfig:
# This is a temporary kludge to let the build system know that we are using the new
# configuration system
2) The way you select applications is different. In the "legacy" appconfig, you had to put the path to each apps/directory in the appconfig file. So for example, if you wanted to build apps/nshlib, you would add:
CONFIGURED_APPS += nshlib
But there is no appconfig file with the automated build. Instead, the apps/nshlib/Kconfig file has:
bool "NSH Library"
Build the NSH support library. This is used, for example, by examples/nsh
in order to implement the full NuttShell (NSH).
So if you want to build the NSH library, then you will get the following definition in the nuttx/.config file:
So the combination of CONFIG_NUTTX_NEWCONFIG=y and CONFIG_NSH_LIBRARY=y is what will cause apps/nshlib to be built or not. You can see this in apps/Makefile. If CONFIG_NUTTX_NEWCONFIG is selected, then it will include apps/nshlib/Make.defs. In apps/nshlib/Make.defs, it will add nshlib to CONFIGURED_APPS if CONFIG_NSH_LIBRARY is selected.
This is, of course, not tested. That is the way the application configuration is intended to work on the "drawing board."