headers
Richard Cochran | 15 Aug 2012 10:25
Picon
Gravatar

make menuconfig build

 

Dear list,

I am trying to get the menuconfig build working. I did 'make
menuconfig' and selected

CONFIG_ARCH_AVR=y
CONFIG_ARCH="avr"
CONFIG_ARCH_FAMILY="avr"
CONFIG_ARCH_CHIP_ATMEGA128=y
CONFIG_ARCH_FAMILY_AVR=y
CONFIG_ARCH_ATMEGA=y
CONFIG_ARCH_BOARD_AMBER=y

When I build, I get the message "Nuttx has not been configured"
triggered from the check_context: Makefile target.

This happens because Make.defs is missing. I can surely copy it from
configs/amber/hello by hand, but my question is, how is this supposed
to work?

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregory N | 15 Aug 2012 15:43
Picon
Favicon
Gravatar

Re: make menuconfig build

 

Hi, Richard,

> I am trying to get the menuconfig build working. I did 'make
> menuconfig' and selected
>
> CONFIG_ARCH_AVR=y
> CONFIG_ARCH="avr"
> CONFIG_ARCH_FAMILY="avr"
> CONFIG_ARCH_CHIP_ATMEGA128=y
> CONFIG_ARCH_FAMILY_AVR=y
> CONFIG_ARCH_ATMEGA=y
> CONFIG_ARCH_BOARD_AMBER=y
>
> When I build, I get the message "Nuttx has not been configured"
> triggered from the check_context: Makefile target.
>
> This happens because Make.defs is missing. I can surely copy it from
> configs/amber/hello by hand, but my question is, how is this supposed
> to work?

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.

But I don't think that we will go that way. At least not right now.

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'

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

There is one minor problem with the because configure.sh does a minor modification at the bottom of the .config file. It appends the path to the apps/ directory. That will have to be revisited to.

But this is not cast in stone and I am certainly open to other, better concepts.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 16 Aug 2012 09:38
Picon
Gravatar

Re: Re: make menuconfig build

 

On Wed, Aug 15, 2012 at 01:43:24PM -0000, Gregory N wrote:
>
> 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.

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.

Ideas?

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 16 Aug 2012 09:54
Picon
Gravatar

Re: Re: make menuconfig build

 

On Wed, Aug 15, 2012 at 01:43:24PM -0000, Gregory N wrote:
>
> 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
scratch.

An important feature of Kbuild is that you can save your .config on
the side. It contains everything you need to reproduce your build
configuration.

With nuttx kbuild in its current state, the .config produced by
menuconfig is not worth very much, since it is not self contained.

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...

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 16 Aug 2012 09:58
Picon
Gravatar

Re: Re: make menuconfig build

 

On Wed, Aug 15, 2012 at 01:43:24PM -0000, Gregory N wrote:
>
> I think that the normal usage model would be:
>

Thanks for this explanation. It does help me to understand the current
Kconfig concept for nuttx.

> 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'
>
> 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?

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregory N | 16 Aug 2012 16:01
Picon
Favicon
Gravatar

Re: make menuconfig build

 

Hi, Richard,

> > 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
> scratch.
>
> An important feature of Kbuild is that you can save your .config on
> the side. It contains everything you need to reproduce your build
> configuration.
>
> 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
ekk-lm3s9b96/scripts
lincoln60/scripts
lpc4330-xplorer/scripts
mcu123-lpc214x/scripts
mirtoo/scripts
olimex-stm32-p107/scripts
olimex-strp711/scripts
stm3210e-eval/scripts
stm32f4discovery/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:

CONFIG_NUTTX_NEWCONFIG=y

This comes from nuttx/Kconfig:

# This is a temporary kludge to let the build system know that we are using the new
# configuration system

config NUTTX_NEWCONFIG
bool
default y

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:

config NSH_LIBRARY
bool "NSH Library"
default n
---help---
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:

CONFIG_NSH_LIBRARY=y

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."

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Michael Smith | 16 Aug 2012 17:55
Picon

Re: make menuconfig build

 


On Aug 16, 2012, at 7:01 AM, Gregory N wrote:

 

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.

...

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. 

I suspect the irony here was unintentional, but still. 8)

The multiple use of the config files makes it very hard to structure ones' configuration; e.g. it would be useful to be able to separate the kernel configuration from the driver config, for example.  Once you have more than one configuration, managing the config files is quite unwieldy.

However, the Kconfig stuff is a mess.  Aside from the practical issues (cmake would have been a better choice, since it's both portable and works with more build systems), the configuration factoring follows the layout of the source tree and the build system, rather than acting as an interface between the user's mental map of the system's dependencies and its implementation.

 = Mike
__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregory N | 16 Aug 2012 21:27
Picon
Favicon
Gravatar

Re: make menuconfig build

 

Hi, Mike,

> > 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.
> >
> ...
>
> > 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.
> >
> I suspect the irony here was unintentional, but still. 8)
> >

But as I continued to say, that intent did not work. There are too many things like '|' and "<<" in the .config files. The .config files cannot be included by Bash scripts. Nor can those same .config files be used with the auto-configuration tool.. at least not without a couple of screens full of errors at start-up. Both tools choke when they hit those characters.

Ultimately, I will need to replace things like

CONFIG_MY_IPADDR=(10<<24|0<<16|0<<8|1)

with

CONFIG_MY_IPADDR=0x0a000001

> However, the Kconfig stuff is a mess. ...

I hope it gets better some day. But no one is really working on it in any organized way... other than Richard for now.

I try to add things into Kconfig files when I just happen to be working in the directory that contains, but I have not particular objectives that I am driving. You may not know the history of how the partial, incomplete auto-configuration got there (I think the bread crumbs are in this mail list).

> ...the configuration factoring follows the layout of the source tree and the build system, rather than acting as an interface between the user's mental map of the system's dependencies and its implementation.

Since there is no vision or direction or intent or owner for the auto-configuratin stuff, this at least supports occasional updates to the Kconfig content.

Its yours if you want it!

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 17 Aug 2012 11:57
Picon
Gravatar

Re: Re: make menuconfig build

 

On Thu, Aug 16, 2012 at 07:27:44PM -0000, Gregory N wrote:
>
> Ultimately, I will need to replace things like
>
> CONFIG_MY_IPADDR=(10<<24|0<<16|0<<8|1)
>
> with
>
> CONFIG_MY_IPADDR=0x0a000001

Yep, and also de-quote the string items in the makefile. One way to do
this is:

export CONFIG_ARCH := $(shell echo $(CONFIG_ARCH))
export CONFIG_ARCH_FAMILY := $(shell echo $(CONFIG_ARCH_FAMILY))

> > However, the Kconfig stuff is a mess. ...
>
> I hope it gets better some day. But no one is really working on it in any organized way... other than Richard for now.

But, did Mike mean that Kconfig itself is a mess, and cmake is a
better tool than kbuild?

(That is what I understood from his comment.)

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Michael Smith | 18 Aug 2012 07:30
Picon

Re: make menuconfig build

 


On Aug 17, 2012, at 2:57 AM, Richard Cochran wrote:

 


> > However, the Kconfig stuff is a mess. ...
>
> I hope it gets better some day. But no one is really working on it in any organized way... other than Richard for now.

But, did Mike mean that Kconfig itself is a mess, and cmake is a
better tool than kbuild?

Kconfig/mconf/etc is a bad tool, and as Greg notes, nobody is giving the build system a lot of love right now.

cmake is a different thing, in that it is a build system generator, and if maintained well can be used to build configuration mechanisms that (IMO, naturally) are easier to use than mconf and friends.

It is also quite aggressively cross-platform, which the current Kconfig setup isn't.

 = Mike



__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 18 Aug 2012 17:47
Picon
Gravatar

Re: make menuconfig build

 

On Fri, Aug 17, 2012 at 10:30:03PM -0700, Michael Smith wrote:
>
> Kconfig/mconf/etc is a bad tool, and as Greg notes,

Sorry, I must have overlooked when he said that.

I guess Kconfig will just have to slink back to ptxdist, buildroot,
busybox, crosstool-NG, openWRT, uClibc, and the linux kernel projects.

> nobody is giving the build system a lot of love right now.

And neither is anyone giving cmake for nuttx much attention, either.

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Michael Smith | 18 Aug 2012 19:22
Picon

Re: make menuconfig build

 


On Aug 18, 2012, at 8:47 AM, Richard Cochran wrote:

 

On Fri, Aug 17, 2012 at 10:30:03PM -0700, Michael Smith wrote:
>
> Kconfig/mconf/etc is a bad tool, and as Greg notes,

Sorry, I must have overlooked when he said that.

I guess Kconfig will just have to slink back to ptxdist, buildroot,
busybox, crosstool-NG, openWRT, uClibc, and the linux kernel projects.

As well as quite a few others that I've used / hacked on.  Yes, I'm aware that it's popular, but I also have some experience with it and its shortcomings, both from an architectural and a typical-application perspective.

> nobody is giving the build system a lot of love right now.

And neither is anyone giving cmake for nuttx much attention, either.

Obviously, but you didn't ask about that, just whether I was asserting it was a better tool. My point in response was that it was different, but quite possibly a more interesting thing from the NuttX perspective.

 = Mike
__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregory N | 19 Aug 2012 00:04
Picon
Favicon
Gravatar

Re: make menuconfig build

 

Mike wrote:
> > Kconfig/mconf/etc is a bad tool, and as Greg notes, nobody is giving the build system a lot of love right now.

There is no owner of that feature. I am not driving the configuration tool. It was started by someone who, unfortunately, got diverted to other tasks before he was able to finalize the implementation. There is no plan as to how the configurator will become "production ready."

I am pleased that Richard has taken some interest and is helping. But if you look at the number of boards and MCUs that have no configuration support, the remaining effort to have a credible configuration system is still quite large.

So although the configurator is getting some "love" now, I still don't see the roadmap on how this ever gets finished.

Mike wrote:
> > cmake is a different thing, in that it is a build system generator, and if maintained well can be used to build configuration mechanisms that (IMO, naturally) are easier to use than mconf and friends.
Richard wrote:
> And neither is anyone giving cmake for nuttx much attention, either.

I subscribe to the "Little Red Hen" school of tool selection:

http://www.speakaboos.com/story/the-little-red-hen/
http://www.childrenstory.info/childrenstories/thelittleredhen.html?cPath=55).
http://www.enchantedlearning.com/stories/fairytale/littleredhen/story/
http://www.youtube.com/watch?v=5QSsqls-R3o&feature=related

I generally think that whoever is willing to contribute the work is free to select the tools that work best for them. mconf was selected by the person that did the original, substantial contribution to the configuration system. I am open to almost any tools that the person doing the work would like to use. The only restrictions on tools that I would place is that they must have availability and portability: They must be readily available at no cost and they must work on all supported platforms and be toolchain agnostic. Ideally, tools should not restrict the development platform.

[I know, I am being hypocritical. My original use of GNU make, Bash, sed, etc. is rooted in the dark past when I never conceived that NuttX would ever be built on anything but Linux. In hindsight, those choices would not meet these criteria. I did remove all of the awk.]

So if cmake satisfies all of these restrictions and someone wishes to contributes the effort to re-tool the build system, I certainly am not opposed.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 20 Aug 2012 11:54
Picon
Gravatar

Re: Re: make menuconfig build

 

On Sat, Aug 18, 2012 at 10:04:56PM -0000, Gregory N wrote:
>
> I generally think that whoever is willing to contribute the work is free to select the tools that work best for them. mconf was selected by the person that did the original, substantial contribution to the configuration system. I am open to almost any tools that the person doing the work would like to use. The only restrictions on tools that I would place is that they must have availability and portability: They must be readily available at no cost and they must work on all supported platforms and be toolchain agnostic. Ideally, tools should not restrict the development platform.

So, what are the supported platforms?

Windows/cygwin and Linux, right?

> [I know, I am being hypocritical. My original use of GNU make, Bash, sed, etc. is rooted in the dark past when I never conceived that NuttX would ever be built on anything but Linux. In hindsight, those choices would not meet these criteria. I did remove all of the awk.]

Using GNU makefiles plus a bit of shell is powerful and can also be
portable. In my experience, the nuttx build system works out of the
box, on both Linux and Windows. I don't see any issue with nuttx's
portability.

Every time I see Yet Another Build System in python, perl, java, etc,
I wonder why people feel the need to invent the wheel all over again.
It seems like people jump right to python/etc will ever learning how
makefiles really work.

> So if cmake satisfies all of these restrictions and someone wishes to contributes the effort to re-tool the build system, I certainly am not opposed.

Maybe I am off base here, (my only experience with cmake was trying to
compile X-windows for Sparc once, and it was *not* easy) but cmake is
not the right tool for nuttx, IMHO. Like GNU autoconf, cmake is for
compiling one application on many different target platforms.

Nuttx doesn't have this problem. The build system needs to run on
Windows (and maybe Linux, too). All of the MCU vendor compilers run on
Windows, and some run *only* on Windows.

The nuttx OS itself must run portably on many different machines, but
that is handled by the cross compiler. Nuttx never does a native
build, and so it doesn't need autoconf or cmake.

What Nuttx does need is a away to manage all of the many different OS
features. As an developer for MCUs, I need to be choosy about having
this and not that, in order to fit into the ram/flash memory
constraints. I need a tool that helps me understand how one option
depends on another.

The kconfig tool helps to manage the many choices. It is used by
projects (like linux, buildroot, etc) that need to bring order to a
chaos of options. These projects do not need to be portable to half a
dozen UNIX flavors. As we all know, kconfig is not perfect, but it is
useful for its intended purpose.

Anyhow, that is my 2 cents.

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kurt Lidl | 20 Aug 2012 16:38

Re: Re: make menuconfig build

 

On Mon, Aug 20, 2012 at 11:54:14AM +0200, Richard Cochran wrote:
> On Sat, Aug 18, 2012 at 10:04:56PM -0000, Gregory N wrote:
> So, what are the supported platforms?
>
> Windows/cygwin and Linux, right?

I would hope that's really "Unix-like operating systems", not not
just "Linux". My first go-around with Nuttx last year was targeting
a baremetal i386, using FreeBSD as the cross-build system. At the
time, it wasn't too hard to get all the stuff to build.

I had less success getting bits generated for a cortex-m3 platform,
but those revolved around toolchain issues, not the build system.

> > [I know, I am being hypocritical. My original use of GNU make, Bash, sed, etc. is rooted in the dark past when I never conceived that NuttX would ever be built on anything but Linux. In hindsight, those choices would not meet these criteria. I did remove all of the awk.]
>
> Using GNU makefiles plus a bit of shell is powerful and can also be
> portable. In my experience, the nuttx build system works out of the
> box, on both Linux and Windows. I don't see any issue with nuttx's
> portability.
>
> Every time I see Yet Another Build System in python, perl, java, etc,
> I wonder why people feel the need to invent the wheel all over again.
> It seems like people jump right to python/etc will ever learning how
> makefiles really work.
>
> > So if cmake satisfies all of these restrictions and someone wishes to contributes the effort to re-tool the build system, I certainly am not opposed.
>
> Maybe I am off base here, (my only experience with cmake was trying to
> compile X-windows for Sparc once, and it was *not* easy) but cmake is
> not the right tool for nuttx, IMHO. Like GNU autoconf, cmake is for
> compiling one application on many different target platforms.

"X-windows" has never used cmake. It used to use imake, but that's
an entirely different beast. X has, for better (or worse) switched
to using autoconf.

-Kurt

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 20 Aug 2012 17:28
Picon
Gravatar

Re: Re: make menuconfig build

 

On Mon, Aug 20, 2012 at 10:38:21AM -0400, Kurt Lidl wrote:
> On Mon, Aug 20, 2012 at 11:54:14AM +0200, Richard Cochran wrote:
> > Maybe I am off base here, (my only experience with cmake was trying to
> > compile X-windows for Sparc once, and it was *not* easy) but cmake is
> > not the right tool for nuttx, IMHO. Like GNU autoconf, cmake is for
> > compiling one application on many different target platforms.
>
> "X-windows" has never used cmake. It used to use imake, but that's
> an entirely different beast. X has, for better (or worse) switched
> to using autoconf.

Okay, never mind, so I really have zero experience with cmake.

Looking at its home page, cmake lists KDE and MySQL as poster
children. Still sound likes it is something like autoconf to me.

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Kurt Lidl | 20 Aug 2012 18:08

Re: Re: make menuconfig build

 

On Mon, Aug 20, 2012 at 05:28:29PM +0200, Richard Cochran wrote:
> On Mon, Aug 20, 2012 at 10:38:21AM -0400, Kurt Lidl wrote:
> > On Mon, Aug 20, 2012 at 11:54:14AM +0200, Richard Cochran wrote:
> > > Maybe I am off base here, (my only experience with cmake was trying to
> > > compile X-windows for Sparc once, and it was *not* easy) but cmake is
> > > not the right tool for nuttx, IMHO. Like GNU autoconf, cmake is for
> > > compiling one application on many different target platforms.
> >
> > "X-windows" has never used cmake. It used to use imake, but that's
> > an entirely different beast. X has, for better (or worse) switched
> > to using autoconf.
>
> Okay, never mind, so I really have zero experience with cmake.
>
> Looking at its home page, cmake lists KDE and MySQL as poster
> children. Still sound likes it is something like autoconf to me.

Cmake is pretty cross-platform. It uses some meta configuration
files to drive the creation of "standard" makefiles (digestable on
any "make", not just "gnumake" -- a huge win in my book), as well
as the creation of workspace configuration for Windows. I do
not know if has hooks to create projects under OS X or not -- it
wouldn't surprise me.

LLVM also has cmake support baked in, and it's apparently quite a
bit faster to run the cmake driven builds of that software, as
opposed the bloated autoconfiguration mess that LLVM also supports.

Autoconfiguration is pretty nice if you're building native software,
in that it can sniff out characteristics of your system and adjust
(via #define in the code) the code to match what your system
supports. Which is great, if one is building native code. But,
for Nuttx, that's not the case. Typically the builder is
targeting one specific board configuration, and the capabilities/
system calls, library calls of the host doing the building do not
really matter. The only thing that matters is the options selected
for the target.

For what Nuttx is attempting to do (cross build an OS for an embedded
target), I would think that Cmake is superior to autoconf. But, I'm
not sure that's the debate, the debate is really:

"Is Cmake better than Kconfig"?

I'd bet that it's easier to make cmake do a native only windows
build of nuttx than getting Kconfig to run on windows, without
Cygwin.

-Kurt

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregory N | 20 Aug 2012 17:32
Picon
Favicon
Gravatar

Re: make menuconfig build

 

--- In nuttx-hHKSG33TihhbjbujkaE4pw@public.gmane.org, Kurt Lidl <lidl <at> ...> wrote:
>
> On Mon, Aug 20, 2012 at 11:54:14AM +0200, Richard Cochran wrote:
> > On Sat, Aug 18, 2012 at 10:04:56PM -0000, Gregory N wrote:
> > So, what are the supported platforms?
> >
> > Windows/cygwin and Linux, right?
>
> I would hope that's really "Unix-like operating systems", not not
> just "Linux". My first go-around with Nuttx last year was targeting
> a baremetal i386, using FreeBSD as the cross-build system. At the
> time, it wasn't too hard to get all the stuff to build.

There really is no list of "supported platforms" -- I probably should not have used that phrase. There are platforms that I personally use and, therefore, I suppose that those are supported in some sense: Windows/Cygwin and Linux both with bash.

Then there are platforms and shells that other people in this list use and they send me changes if the build for those platforms get broken: FreeBSD and OSX. I don't know if that counts as "supported" or not.

The term "supported platform" sounds like legalese to protect someone or to limit some liability. I don't want to limit the support for any platform and I will help anyone to get the NuttX building on their platform of choice.

I don't want to do anything that specifically limits support for a particular environment (at least, not any more so than I have already done).

And, of course, there is that elephant in the room..

I think that it is important to someday get a native Windows build, for example. That doesn't work now and there would be a lot of effort to get there. But this is the platform that most MCU vendors support with tools and the platform that most MCU developers use. So Windows should be on the to-be-supported list.

If you are currently using a Windows native toolchain and building NuttX under Cygwin, then there are several build features that do not work correctly: Symbolic links get replaced by be dumb directory copies (which causes me no end of problems) and there are no dependencies in the build at all.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Richard Cochran | 17 Aug 2012 12:15
Picon
Gravatar

Re: Re: make menuconfig build

 

On Thu, Aug 16, 2012 at 02:01:52PM -0000, Gregory N wrote:
> Hi, Richard,
>
> > > 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.

They are, in fact, not different. They are *identical* for most of
those macros listed.

find configs -name Make.defs | xargs grep -A 3 PREPROCESS
find configs -name Make.defs | xargs grep -A 3 CXXFLAGS

... and so on.

[ You can hardly say that HOSTCC depends in any way upon the
arch/board/app setting. ]

> > 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.

It already is a problem, at least for me. Rather than complaining too
much, I will just send some patches for you to consider.

> 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.

( I am not suggesting adding spagetti code, just improving what you
already have ;)

> 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.

Well, having gone through the exercise of getting the Kconfig build to
work at all, I think the build system could use some cleaning up, step
by step, of course.

Thanks,
Richard

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |

Gmane