ghaerr commented on issue #18566:
URL: https://github.com/apache/nuttx/issues/18566#issuecomment-4642310575
> some idea how to provide configuration options through additional/optional
may be even generated header file into Microwindows to not flood NuttX CFLAGS
by lot of Microwindows specific defines.
Decades ago, back when Microwindows was getting ported to lots of differing
systems, a contribution was accepted which implemented the still-used
recursive-Makefile approach to building Microwindows and Nano-X. This used a
`config` file to designate many options which were then effectively translated
to compilation/link flags using Arch.rules, Makefile.rules,
drivers/Objects.rules, etc. While this worked well at the time, nowadays IMO it
hinders adding new systems due to the complexity involved.
After that, a contribution was accepted which attempted a simpler approach
to building the system which used Makefile_nr (non-recursive) in various
directories. This still supports DJGPP and certain older DOS compilations, but
I think remains rather messy.
For NuttX, I would suggest something close to the route taken most recently,
when Nano-X was ported to ELKS. This is quite simple and only uses two
makefiles, src/Makefile.elks to build the client library(s) and
demos/nanox/Makefile.elks to build desired applications. No config file is used
and compilation options like CFLAGS etc are all in the Makefile.elks. By
starting with Makefile.elks renamed to Makefile.nuttx, a path close to @ppisa's
roadmap above should be simple to implement, without having to bother with all
the previous config/Makefile issues.
This method builds using the following two commands easily placed in a shell
script:
```
$ make -f Makefile.elks clean
$ make -f Makefile.elks
```
and produces libs and binaries in src/lib and src/bin.
Using the above approach then leaves the issue of where the various (many)
project-specific options might be stored. In later years, and certainly for
ELKS, the many project options (e.g. HAVE_FONT_SUPPORT, MW_FEATURE_IMAGES, etc)
were placed in include/mwconfig.h, and in the ELKS case right now, all options
are contained within an `#if ELKS/#endif` block.
While this approach could work for NuttX, perhaps moving NUTTX (and ELKS)
options out of mwconfig.h into a port-specific header file would allow for
keeping most all NUTTX (and ELKS) options and source code within their own
files, which will be much easier to maintain in the master branch. To do this,
perhaps using a couple C preprocessor include macros would nicely solve this
problem (for both NuttX and ELKS):
In Makefile.nuttx:
```
...
CFLAGS += -DNUTTX=1
CFLAGS += -DMWCONFIG='"mwconfig.nuttx"'
...
```
In include/mwconfig.h (at the top):
```
#ifdef MWCONFIG
#define INCFILE(name) name
#include INCFILE(MWCONFIG)
#endif
```
Then all NuttX-specific options in a new file include/mwconfig.nuttx (e.g.
these are from \#if ELKS in mwconfig.h):
```
/* NuttX configuration options */
#define NANOWM 1 /* =1 for builtin nano-X window manager*/
#define USE_ALLOCA 0 /* =1 if alloca() is available*/
#define HAVE_MMAP 0 /* =1 has mmap system call*/
#define HAVE_SIGNAL 1 /* =1 has signal system call*/
#define HAVE_FILEIO 0 /* =1 to include libc stdio and image
reading routines*/
#define HAVE_BMP_SUPPORT 0 /* BMP image support*/
#define HAVE_FNT_SUPPORT 0 /* Microwindows FNT font support*/
#define HAVE_PCF_SUPPORT 0 /* PCF font support*/
#define POLYREGIONS 0 /* =1 includes polygon regions*/
#define DYNAMICREGIONS 0 /* =1 to use more complex MWCLIPREGION
regions*/
#define MW_FEATURE_TIMERS 0 /* =1 to include MWTIMER support */
#define MW_FEATURE_BITMAPS 1 /* =1 to enable GrBitmap */
#define MW_FEATURE_IMAGES 0 /* =1 to enable GdLoadImage/GdDrawImage etc*/
#define MW_FEATURE_SHAPES 0 /* =1 for arc, ellipse, polygons,
tile/stipple*/
#define MW_FEATURE_INTL 0 /* =1 for dbcs and TEXTIP_EXTENDED
font/encoding support*/
#define MW_FEATURE_PORTRAIT 0 /* =1 for portrait support */
#define MW_FEATURE_PALETTE 1 /* =1 for palette support*/
#define SCREEN_DEPTH 4
#define MW_FEATURE_AREAS 0 /* =1 for GrArea, GrReadArea, GrStretchArea
*/
#define MW_FEATURE_TINY 1 /* =1 to drop various less-used features */
#define MW_FEATURE_CLIENTDATA 0 /* =1 for copy/paste support */
#define TRANSLATE_ESCAPE_SEQUENCES 1 /* =1 to parse fnkeys w/tty driver*/
#define NUKLEARUI 1 /* =0 to use older tan windows-style 3d
window frame drawing/colors*/
#define OUTLINE_MOVE 1 /* =1 draw outline only during window move*/
#define NO_AUTO_MOVE 1 /* =1 don't auto position window on new
windows*/
#define BIN_NANOX "/bin/nano-x" /* location of Nano-X for
AUTO_START_SERVER */
```
If you like, I could prepare a commit for ELKS which uses this method for
use as a template; this would clean up the ELKS port and prepare for your port.
> the final state and goal should be to include NuttX screen, mouse and
keyboard drivers into mainline Micowidows tree
Yes, the NuttX-specific screen, mouse and keyboard drivers should go in
src/drivers/{scr_nuttx.c,mou_nuttx.c,kbd_nuttx.c} unless a standard driver can
be used.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
