Gregory N
2013-01-06 17:46:31 UTC
Yesterday I released NuttX-6.24 with the first "advertised" native Windows build support. There are still two big missing parts: (1) a configure.sh counterpart, and much more importanly (2) mconf running natively under in a CMD.exe shell under Windows.
Since writing that, I have solved (1). There is now a tools/configure.bat and a tools/configure.c. The configure.bat is just a thin layer: If checks if configure.exe exists, then executes it to instantiate the configuration. If configure.exe does not exist, then it first creates it using minggw-gcc.exeBut (2) is still an issue.
Lately, I have been tinkering with pieces of kconfig-frontends and I am pretty sure that I could do something like the following:
The kconfig-frontends depends on low-level YACC/LEX code. The YACC/LEX code generates a data set describing the configuration and provides C interfaces to manage the configuration data set. This is the "back end" used by all of the kconfig-frontends: The frontends basically provide the different user experience and the backend manages the configuration.
The C code generated from the YACC/LEX has no dependencies at all (other than libintl which is not a big issue) and so is portable. The frontends (other than 'conf') do have major system dependencies and, hence, are the root of the portability problem.
I believe that I could modify the YACC code so that instead of generating a data set it would generate another interpreted program. In fact, the logic for create such a program for the case of Tcl/Tk already exists in the Linux 2.4 kernel. See for example, http://fxr.watson.org/fxr/source/scripts/?v=linux-2.4.22.
The format of the configuration files was different in the 2.4 kernel (Config.in files vs Kconfig files), but functionally equivalent.
When you did 'make xconfig' in the 2.4 kernel, a two step process was initiated. In the first step, the logic in scripts/Makefile ran. The kconfig.tk target in that Makefile created the Tcl program. Then in the second step, the top-level Makefile executed the Tcl/Tk program. The configuration was then done with the Tcl/Tk GUI which is nicer than the mconf GUI, but not as nice as the gconf GUI.
The file scripts/tkparse.c did all of the work and could easily be leveraged to generate a Tcl program in the same way (http://fxr.watson.org/fxr/source/scripts/tkparse.c?v=linux-2.4.22). That would be almost free. Tcl/Tk is available for Windows, but it not so commonly used.
The reason later kernels did not use Tcl/Tk is due largely to the fact that many people do not like Tcl/Tk. But perhaps a similar configuration strategy using some Windows-friendly scripting language like C# or Java/Swing might be appropriate?
So let me re-phrase the problem:
1) The kconfig-frontends works nicely in many environments (Linux, Cygwin, ..), but not native Windows. It cannot be build directly under native Windows. You cannot even configure it under Windows because the configuration script is bash script.
2) There are some round-about ways to get a Windows kconfig-frontends mconf executable. (a) Using MSYS, but the build process is much more complex than the average person can handle and there are bugs in pdcurses that prevent it from working properly. Or (b) using Cygwin but this requires a large installation and the tool will not work properly outside of the Cygwin "sandbox" without a lot of special setup.
One alternative is to:
Use a simple C program to auto-generate a Windows-compatible script to do the configuration. The creation program would only depend on mingw-gcc and the generated script would to fully compatible with the Windows environment, perhaps C# or Java/Swing.
Any inputs? As you see, I am still struggling with a solution that the would work well, be easy to use and would not require many special tools.
Any thoughts?
Greg