Removed all support for the legacy configuration mechanism from the apps/ directory
This commit is contained in:
Gregory Nutt
parent
23672d2bbe
commit
b19e1aa426
@ -855,4 +855,7 @@
|
||||
returned IP address is already in host order.
|
||||
* apps/netutils/dhcpd/Kconfig: Add missing DHCPD configuratino
|
||||
settings(2014-3-3).
|
||||
* Support for the legacy configuration mechanism (using appconfig files)
|
||||
is removed. Only the newer configuration using the kconfig-frontends
|
||||
tools is now supported (2014-3-6).
|
||||
|
||||
|
||||
@ -36,11 +36,7 @@
|
||||
|
||||
BUILTIN_REGISTRY = $(APPDIR)$(DELIM)builtin$(DELIM)registry
|
||||
|
||||
ifeq ($(CONFIG_NUTTX_NEWCONFIG),y)
|
||||
DEPCONFIG = $(TOPDIR)$(DELIM).config
|
||||
else
|
||||
DEPCONFIG = $(TOPDIR)$(DELIM).config $(APPDIR)$(DELIM).config
|
||||
endif
|
||||
|
||||
ifeq ($(CONFIG_WINDOWS_NATIVE),y)
|
||||
define REGISTER
|
||||
|
||||
39
Makefile
39
Makefile
@ -42,8 +42,7 @@ APPDIR = ${shell pwd}
|
||||
# Application Directories
|
||||
|
||||
# CONFIGURED_APPS is the list of all configured built-in directories/built
|
||||
# action. It is created by the configured appconfig file (a copy of which
|
||||
# appears in this directory as .config)
|
||||
# action.
|
||||
# SUBDIRS is the list of all directories containing Makefiles. It is used
|
||||
# only for cleaning. builtin must always be the first in the list. This
|
||||
# list can be extended by the .config file as well.
|
||||
@ -52,25 +51,16 @@ CONFIGURED_APPS =
|
||||
SUBDIRS = examples graphics interpreters modbus builtin nshlib netutils
|
||||
SUBDIRS += platform system
|
||||
|
||||
# There are two different mechanisms for obtaining the list of configured
|
||||
# directories:
|
||||
# The list of configured directories is derived from NuttX configuration
|
||||
# file: The selected applications are enabled settings in the confuration
|
||||
# file. For example,
|
||||
#
|
||||
# (1) In the legacy method, these paths are all provided in the appconfig
|
||||
# file that is copied to the top-level apps/ directory as .config
|
||||
# (2) With the development of the NuttX configuration tool, however, the
|
||||
# selected applications are now enabled by the configuration tool.
|
||||
# The apps/.config file is no longer used. Instead, the set of
|
||||
# configured build directories can be found by including a Make.defs
|
||||
# file contained in each of the apps/subdirectories.
|
||||
# CONFIG_EXAMPLES_HELLO=y
|
||||
#
|
||||
# When the NuttX configuration tools executes, it will always define the
|
||||
# configure CONFIG_NUTTX_NEWCONFIG to select between these two cases. Then
|
||||
# legacy appconfig files will still work but newly configuration files will
|
||||
# also work. Eventually the CONFIG_NUTTX_NEWCONFIG option will be phased
|
||||
# Will cause the "Hello, World!" example at apps/examples/hello to be
|
||||
# built and added int libapps.a.
|
||||
# out.
|
||||
|
||||
ifeq ($(CONFIG_NUTTX_NEWCONFIG),y)
|
||||
|
||||
# builtin/Make.defs must be included first
|
||||
|
||||
include builtin/Make.defs
|
||||
@ -91,19 +81,6 @@ include system/Make.defs
|
||||
|
||||
INSTALLED_APPS =
|
||||
|
||||
# The legacy case:
|
||||
|
||||
else
|
||||
-include .config
|
||||
|
||||
# INSTALLED_APPS is the list of currently available application directories. It
|
||||
# is the same as CONFIGURED_APPS, but filtered to exclude any non-existent
|
||||
# application directory. builtin is always in the list of applications to be
|
||||
# built.
|
||||
|
||||
INSTALLED_APPS = builtin
|
||||
endif
|
||||
|
||||
# Create the list of available applications (INSTALLED_APPS)
|
||||
|
||||
define ADD_BUILTIN
|
||||
@ -181,7 +158,6 @@ ifeq ($(CONFIG_WINDOWS_NATIVE),y)
|
||||
$(Q) for %%G in ($(SUBDIRS)) do ( \
|
||||
$(MAKE) -C %%G distclean TOPDIR="$(TOPDIR)" APPDIR="$(APPDIR)" \
|
||||
)
|
||||
$(call DELFILE, .config)
|
||||
$(call DELFILE, .depend)
|
||||
$(Q) ( if exist external ( \
|
||||
echo ********************************************************" \
|
||||
@ -192,7 +168,6 @@ else
|
||||
$(Q) for dir in $(SUBDIRS) ; do \
|
||||
$(MAKE) -C $$dir distclean TOPDIR="$(TOPDIR)" APPDIR="$(APPDIR)"; \
|
||||
done
|
||||
$(call DELFILE, .config)
|
||||
$(call DELFILE, .depend)
|
||||
$(Q) ( if [ -e external ]; then \
|
||||
echo "********************************************************"; \
|
||||
|
||||
85
README.txt
85
README.txt
@ -95,36 +95,9 @@ after the NSH command.
|
||||
|
||||
Application Configuration File
|
||||
------------------------------
|
||||
The old-style NuttX configuration uses a special configuration file is
|
||||
used to configure which applications are to be included in the build.
|
||||
The source for this file is configs/<board>/<configuration>/appconfig.
|
||||
The existence of the appconfig file in the board configuration directory
|
||||
is sufficient to enable building of applications.
|
||||
|
||||
The appconfig file is copied into the apps/ directory as .config when
|
||||
NuttX is configured. .config is included in the toplevel apps/Makefile.
|
||||
As a minimum, this configuration file must define files to add to the
|
||||
CONFIGURED_APPS list like:
|
||||
|
||||
CONFIGURED_APPS += examples/hello system/poweroff
|
||||
|
||||
The new NuttX configuration uses kconfig-frontends tools and only the
|
||||
NuttX .config file. The new configuration is indicated by the existence
|
||||
of the definition CONFIG_NUTTX_NEWCONFIG=y in the NuttX .config file.
|
||||
If CONFIG_NUTTX_NEWCONFIG is defined, then the Makefile will:
|
||||
|
||||
- Assume that there is no apps/.config file and will instead
|
||||
- Include Make.defs files from each of the subdirectories.
|
||||
|
||||
When an application is enabled using the kconfig-frontends tool, then
|
||||
a new definition is added to the NuttX .config file. For example, if
|
||||
you want to enable apps/examples/hello then the old apps/.config would
|
||||
have had:
|
||||
|
||||
CONFIGURED_APPS += examples/hello
|
||||
|
||||
But in the new configuration there will be no apps/.config file and,
|
||||
instead, the NuttX .config will have:
|
||||
The NuttX configuration uses kconfig-frontends tools and the NuttX
|
||||
configuration file (.config) file. For example, the NuttX .config
|
||||
may have:
|
||||
|
||||
CONFIG_EXAMPLES_HELLO=y
|
||||
|
||||
@ -138,43 +111,11 @@ This will select the apps/examples/hello in the following way:
|
||||
CONFIGURED_APPS += examples/hello
|
||||
endif
|
||||
|
||||
Thus accomplishing the same thing with no apps/.config file.
|
||||
|
||||
Example Built-In Application
|
||||
----------------------------
|
||||
An example application skeleton can be found under the examples/hello
|
||||
sub-directory. This example shows how a builtin application can be added
|
||||
to the project. One must define:
|
||||
|
||||
Old configuration method:
|
||||
|
||||
1. Create sub-directory as: appname
|
||||
|
||||
2. In this directory there should be:
|
||||
|
||||
- A Makefile, and
|
||||
- The application source code.
|
||||
|
||||
3. The application source code should provide the entry point:
|
||||
appname_main()
|
||||
|
||||
4. Set the requirements in the file: Makefile, specially the lines:
|
||||
|
||||
APPNAME = appname
|
||||
PRIORITY = SCHED_PRIORITY_DEFAULT
|
||||
STACKSIZE = 768
|
||||
ASRCS = asm source file list as a.asm b.asm ...
|
||||
CSRCS = C source file list as foo1.c foo2.c ..
|
||||
|
||||
Look at some of the other Makefiles for examples. Note the
|
||||
special registration logic needed for the context: target
|
||||
|
||||
5. Add the to the application to the CONFIGIURED_APPS in the
|
||||
apps/.config file:
|
||||
|
||||
CONFIGURED_APPS += appname
|
||||
|
||||
New Configuration Method:
|
||||
to the project. One must:
|
||||
|
||||
1. Create sub-directory as: appname
|
||||
|
||||
@ -253,10 +194,8 @@ A: Here are four:
|
||||
|
||||
tools/configure.sh MyBoard/MyConfiguration
|
||||
|
||||
or simply by copying defconfig->nutt/.config,
|
||||
setenv.sh->nuttx/setenv.sh, and Make.defs->nuttx/Make.defs
|
||||
(and appconfig->apps/.config for the old-style, deprecated
|
||||
configuration files).
|
||||
or simply by copying defconfig->nuttx/.config,
|
||||
setenv.sh->nuttx/setenv.sh, and Make.defs->nuttx/Make.defs.
|
||||
|
||||
Using the 'external' link makes it especially easy to add a
|
||||
'built-in' application an existing configuration.
|
||||
@ -264,11 +203,11 @@ A: Here are four:
|
||||
4) Add any link to apps/
|
||||
|
||||
a) Add symbolic links apps/ to as many other directories as you
|
||||
want.
|
||||
b) Then just add the (relative) paths to the links in your
|
||||
appconfig file (that becomes the apps/.config file).
|
||||
want,
|
||||
b) Add the symbolic link to the list of candidate paths in the
|
||||
top level apps/Makefile, and
|
||||
b) Add the (relative) paths to the CONFIGURED_APPS list
|
||||
in the Make.defs file in your new directory.
|
||||
|
||||
That is basically the same as my option #3 but doesn't use the
|
||||
magic 'external' link. The toplevel apps/Makefile will always
|
||||
to build whatever in finds in the apps/.config file (plus the
|
||||
external link if present).
|
||||
magic 'external' link.
|
||||
|
||||
@ -24,21 +24,6 @@ examples
|
||||
"named" applications that can be executed from the NSH
|
||||
command line (see apps/README.txt for more information).
|
||||
|
||||
Older configurations.
|
||||
|
||||
Older, deprecated configuration files might use a variable called
|
||||
CONFIGURED_APPS to selected examples. Those CONFIGURED_APPS settings
|
||||
where kept in files called appconfig. For example, in those older
|
||||
configuration files, the OS test example would have been selected with
|
||||
an entry like the following in the appconfig file:
|
||||
|
||||
CONFIGURED_APPS += examples/ostest
|
||||
|
||||
appconfig files are not longer used in the current NuttX configuration
|
||||
system. And syntax like the above is being phased out (but is still
|
||||
supported by the make system butonly until the last configuration is
|
||||
converted to the newer style configuration files).
|
||||
|
||||
examples/adc
|
||||
^^^^^^^^^^^^
|
||||
|
||||
|
||||
@ -60,15 +60,3 @@ pcode
|
||||
|
||||
CONFIG_EXAMPLES_PASHELLO=y
|
||||
CONFIG_INTERPRETERS_PCODE=y
|
||||
|
||||
Old Style (deprecated). In the older configuration files, you would have
|
||||
used an appconfig file containing the following definitions in order to
|
||||
accomplish the same thing:
|
||||
|
||||
# Path to example in apps/examples containing the passhello_main entry point
|
||||
|
||||
CONFIGURED_APPS += examples/pashello
|
||||
|
||||
# Path to the Pascal p-code runtime interpreter module
|
||||
|
||||
CONFIGURED_APPS += interpreters/pcode
|
||||
|
||||
@ -34,14 +34,7 @@ information as "recommendations" -- not necessarily proven instructions.
|
||||
|
||||
CONFIG_INTERPRETERS_FICL=y
|
||||
|
||||
Deprecated: In the older style configuration, you would have used
|
||||
an appconfig file to include (1) the path to your application code,
|
||||
and (2) the path to the Ficl build directory. That latter would
|
||||
have appeared as the following line in your appconfig file:
|
||||
|
||||
CONFIGURED_APPS += interpreters/ficl
|
||||
|
||||
6. Configure and build NuttX. On successful completion, the Ficl objects
|
||||
will be available in apps/libapps.a and that NuttX binary will be
|
||||
linked against that file. Of course, Ficl will do nothing unless
|
||||
you have written some application code that uses it!
|
||||
6. Configure and build NuttX. On successful completion, the Ficl objects
|
||||
will be available in apps/libapps.a and that NuttX binary will be
|
||||
linked against that file. Of course, Ficl will do nothing unless
|
||||
you have written some application code that uses it!
|
||||
|
||||
@ -351,11 +351,6 @@ The I2C tools requires the following in your NuttX configuration:
|
||||
|
||||
CONFIG_SYSTEM_I2C=y
|
||||
|
||||
Deprecated. In the older style configuration, there would have been
|
||||
an appconfig file containing the path to the I2C tool directory like:
|
||||
|
||||
CONFIGURE_APPS += system/i2c
|
||||
|
||||
2. Device-specific I2C support must be enabled. The I2C tool will call the
|
||||
platform-specific function up_i2cinitialize() to get instances of the
|
||||
I2C interface and the platform-specific function up_i2cuninitialize()
|
||||
|
||||
Loading…
Reference in New Issue
Block a user