nuttx/boards/z80/z8/z8f64200100kit
chao.an b88561299b make/expression: improving up asm/C/C++ compile times
In the current compilation environment, the recursive assignment(=) for compile
flags will be delayed until every file is actually need to be compile.

For example:
--------------------------------------------------------------------------------
arch/arm/src/Makefile:

INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)chip}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)common}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(ARCH_SRCDIR)$(DELIM)$(ARCH_SUBDIR)}
INCLUDES += ${shell $(INCDIR) "$(CC)" $(TOPDIR)$(DELIM)sched}

CPPFLAGS += $(INCLUDES) $(EXTRAFLAGS)
CFLAGS += $(INCLUDES) $(EXTRAFLAGS)
CXXFLAGS += $(INCLUDES) $(EXTRAFLAGS)
AFLAGS += $(INCLUDES) $(EXTRAFLAGS)
--------------------------------------------------------------------------------

All compilation options will be included recursively,
which will be delayed until the compilation options are actually used:

tools/Config.mk:

--------------------------------------------------------------------------------
define COMPILE
  @echo "CC: $1"
  $(Q) $(CC) -c $(CFLAGS) $($(strip $1)_CFLAGS) $1 -o $2
endef
--------------------------------------------------------------------------------

All compile flags to be reexecuted $(INCDIR) as long as one file needs to be compiled,
but in fact, the compilation options have not changed in the current directory.

So the we recommand to change the syntax of assignment
From
    Recursive (=)
To
    Simple    (:=)

In this way, we can ensure that all compilation options are expanded only once and reducing repeated works.

Signed-off-by: chao.an <anchao@xiaomi.com>
2020-11-02 07:53:53 -08:00
..
configs/ostest libc/stdio: Allocate file_struct dynamically 2020-09-11 17:58:17 +08:00
include Refine the preprocessor conditional guard style (#190) 2020-01-31 19:07:39 +01:00
scripts make/expression: improving up asm/C/C++ compile times 2020-11-02 07:53:53 -08:00
src build: Remove the empty variable assignment 2020-05-24 08:24:13 -06:00
Kconfig
README.txt Merged in alinjerpelea/nuttx (pull request #971) 2019-08-09 13:22:39 +00:00

README.txt
^^^^^^^^^^

ZDS-II Compiler Versions
^^^^^^^^^^^^^^^^^^^^^^^^

4.10.1
  The ZDS-II version 4.10.2 will not compile NuttX.  It reports "internal
  errors" on one of the files, mm/mm_initialize.c.  Below is a simple work-
  around.  With this work-around in place, NuttX builds successfully with
  the 4.10.1 compiler.

    --- mm/mm_initialize.c.SAVE	2008-02-13 08:06:46.833857700 -0600
    +++ mm/mm_initialize.c	2008-02-13 08:07:26.367608900 -0600
    @@ -94,8 +94,11 @@
    {
       int i;

    +#if 0 /* DO NOT CHECK IN */
       CHECK_ALLOCNODE_SIZE;
       CHECK_FREENODE_SIZE;
    +#endif

   /* Set up global variables */

Version 4.9.5
  This is the latest tool version listed on the ZiLOG site for the Z8F6403.
  However, it uses different compiler command line arguments.

Version 5.0.0

  On November 28, 2012, all of the z8 configurations were converted to use 5.0.0,
  but have not been verified on a running target.

  Paths were also updated that are specific to a 32-bit toolchain running on
  a 64 bit windows platform.  Change to a different toolchain, you will need
  to modify the versioning in the Make.defs file; if you want to build
  on a different platform, you will need to change the path in the ZDS binaries
  in those that file and also in your PATH variable.

Other Versions
  If you use any version of ZDS-II other than 5.0.0 or if you install ZDS-II
  at any location other than the default location, you will have to modify
  the boards/z80/z8/z8f64200100kit/*/Make.defs file and also your PATH
  environment variable.

  It has been a long time since the z8 port has been used.  A lot has
  changed so it would most likely require a modest effort to get the
  compilation working again.

Configuration Subdirectories
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- src/ and include/
    These directories contain common logic for all z8f64200100kit
    configurations.

Variations on the basic z8f64200100kit configuration are maintained
in subdirectories.  To configure any specific configuration, do the
following steps:

   tools/configure.sh z8f64200100kit:<sub-directory>
   make

Where <sub-directory> is the specific board configuration that you
wish to build.  The following board-specific configurations are
available:

- ostest
    This builds the examples/ostest application for execution from FLASH.
    See examples/README.txt for information about ostest.

    NOTES:

    1. This configuration uses the mconf-based configuration tool.  To
       change this configuration using that tool, you should:

       a. Build and install the kconfig-mconf tool.  See nuttx/README.txt
          see additional README.txt files in the NuttX tools repository.

       b. Execute 'make menuconfig' in nuttx/ in order to start the
          reconfiguration process.

    2. By default, this configuration assumes that you are using the
       Cygwin environment on Windows.  An option is to use the native
       CMD.exe window build as described in the top-level README.txt
       file.  To set up that configuration:

       -CONFIG_WINDOWS_CYGWIN=y
       +CONFIG_WINDOWS_NATIVE=y

       And after configuring, make sure that CONFIG_APPS_DIR uses
       the back slash character.  For example:

        CONFIG_APPS_DIR="..\apps"

      NOTES:

      a. If you need to change the toolchain path used in Make.defs, you
         will need to use the short 8.3 filenames to avoid spaces.  On my
         PC, C:\PROGRA~1\ is is C:\Program Files\ and C:\PROGRA~2\ is
         C:\Program Files (x86)\
      b. At present, the native Windows build fails at the final link stages.
         The failure is due to problems in arch/z80/src/nuttx.linkcmd that
         is autogenerated by arch/z80/src/Makefile.zdsii.  The basic problem
         is the spurious spaces and and carrirage returns are generated at
         the end of the lines after a line continuation (\ ^M).  If these
         trailing bad characters are manually eliminated, then the build
         will succeed on the next try.

Check out any README.txt files in these <sub-directory>s.