Removed all support for the legacy configuration mechanism from the apps/ directory

8 files changed, 26 insertions, 152 deletions

diff --git a/apps/ChangeLog.txt b/apps/ChangeLog.txt
index 80467ec10..32c7abf49 100644
--- a/apps/ChangeLog.txt
+++ b/apps/ChangeLog.txt
@@ -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).
 
diff --git a/apps/Make.defs b/apps/Make.defs
index bdc36e748..77007503b 100644
--- a/apps/Make.defs
+++ b/apps/Make.defs
@@ -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
diff --git a/apps/Makefile b/apps/Makefile
index bc0959106..3be4a1d99 100644
--- a/apps/Makefile
+++ b/apps/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 "********************************************************"; \
diff --git a/apps/README.txt b/apps/README.txt
index 4451ef03f..ea5d9e9ca 100644
--- a/apps/README.txt
+++ b/apps/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.
diff --git a/apps/examples/README.txt b/apps/examples/README.txt
index c64e62da0..42ba317bd 100644
--- a/apps/examples/README.txt
+++ b/apps/examples/README.txt
@@ -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
 ^^^^^^^^^^^^
 
diff --git a/apps/interpreters/README.txt b/apps/interpreters/README.txt
index 667268809..9023ee5a5 100644
--- a/apps/interpreters/README.txt
+++ b/apps/interpreters/README.txt
@@ -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
diff --git a/apps/interpreters/ficl/README.txt b/apps/interpreters/ficl/README.txt
index 57e370338..73ed9006f 100644
--- a/apps/interpreters/ficl/README.txt
+++ b/apps/interpreters/ficl/README.txt
@@ -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!
diff --git a/apps/system/i2c/README.txt b/apps/system/i2c/README.txt
index ee49e7d84..bb4abc831 100644
--- a/apps/system/i2c/README.txt
+++ b/apps/system/i2c/README.txt
@@ -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()