changeset 290:3ecf91f6663a

Update instructions for building the host-side software
author bartv
date Tue, 13 Aug 2002 20:10:16 +0000
parents bd1db6a90df9
children c1c3d5198fe3
files ChangeLog README.host host/README host/tools/configtool/ChangeLog host/tools/configtool/standalone/win32/ReadMe
diffstat 5 files changed, 443 insertions(+), 383 deletions(-) [+]
line wrap: on
line diff
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2002-08-13  Bart Veer  <bartv@ecoscentric.com>
+
+	* README.host: update host-side build instructions
+	
 2002-08-03  Bart Veer  <bartv@ecoscentric.com>
 
 	* acinclude.m4, configure.in, Makefile.am:
new file mode 100644
--- /dev/null
+++ b/README.host
@@ -0,0 +1,344 @@
+		eCos Host-side Software
+		=======================
+
+This README file only describes the eCos host-side software. For
+details of the eCos target-side software or the required toolchains,
+please see other documentation. A good starting point is
+http://sources.redhat.com/ecos
+		
+There are two categories of host-side software. The host subdirectory
+contains generic software, primarily related to the eCos configuration
+technology. All eCos users will need to use some of this technology to
+configure and build eCos, either using pre-built binaries or by
+building the host-side software from source. The generic software
+should be portable to a wide range of host platforms.
+
+There is also package-specific host-side software. Much of this is I/O
+related. For example the generic USB-slave package contains some
+programs related to testing; a test application is run on a target
+with suitable USB slave-side hardware, and needs to interact with
+another program running on the USB host; the latter is
+package-specific host-side software and can be found in the
+subdirectory packages/io/usb/slave. Code like this may have
+significant platform dependencies and may only work on a single
+platform or on a small number of platforms. There may also be
+special requirements, for example it may be necessary to install some
+programs suid root so that they have appropriate access to the
+hardware. 
+
+
+The host subdirectory includes the following:
+
+infra/
+    This is an implementation of the eCos infrastructure that can be
+    used on the host-side, and provides assertion, tracing and
+    testcase support.
+
+    NOTE: the eCos infrastructure facilities are not especially
+    well-suited to host-side development, in particular they are not
+    C++-oriented. There are plans to remove the current infrastructure
+    completely and replace it with something more suitable. People
+    planning new projects should be aware of this, and may wish to
+    avoid using the current infrastructure.
+
+libcdl/
+    The CDL library lies at the heart of the eCos configuration
+    technology. 
+
+tools/configtool/
+    The sources to the various configuration tools can be found here.
+
+tools/configtool/common/common/
+    Contains sources related to makefile generation, shared by the
+    command line and graphical tools.
+
+tools/configtool/standalone/common/
+    Contains the command line ecosconfig tool.
+
+tools/configtool/standalone/wxwin/
+    Contains sources for the wxWindows-based, Linux and Windows graphical
+    configuration tool. The Windows version can currently only be
+    built with Visual C++, not with cygwin g++.
+    
+tools/configtool/common/win32/
+tools/configtool/standalone/win32/
+    Contains sources for the older, MFC-based, Windows-only graphical
+    configuration tool. Again this can currently only be built with
+    Visual C++.
+
+The two graphical configuration tools have their own build procedures,
+described in tools/configtool/standalone/wxwin/ReadMe and
+tools/configtool/standalone/win32/ReadMe respectively.
+
+Package-specific host-side code lives in the host subdirectory of the
+appropriate package, for example packages/io/usb/slave/<version>/host.
+Most packages only provide target-side code and hence will not have a
+host subdirectory. Users can install various packages from a variety
+of sources, and where a package does have host-side software the
+package documentation should be consulted for further information.
+
+
+Installing on Linux and Other Unix Systems
+------------------------------------------
+
+Both generic host-side software (infra, libcdl and ecosconfig) and
+package-specific software can be built with the conventional
+"configure/make/make install" sequence. However the code does not
+conform fully to GNU coding standards so some operations such as "make
+dist" are not supported. There is limited support for DejaGnu-based
+testing.
+
+Much of the host-side software has a dependency on Tcl. This is not
+supplied with the sources since many users will already have a
+suitable installation, for example it is shipped as standard with
+all major Linux distributions. Any release of Tcl from 8.0 onwards
+should  be usable.
+
+There are two main approaches to building the host-side software:
+
+1) build the generic and the package-specific code in one build tree.
+   This uses the top-level configure script. The script automatically
+   invokes the configure script in the main host subdirectory. In
+   addition it searches the packages hierarchy for host subdirectories
+   containing their own configure scripts and will invoke those.
+
+   Note: the search for host subdirectories happens during configure
+   time, not during the make. If new packages with host-side code are
+   added to the repository then it will be necessary to re-run the
+   toplevel configure script.
+
+2) build the generic code in one build tree, using the configure
+   script in the toplevel's host subdirectory. Then build some or all
+   of the package-specific code in separate build trees, using the
+   configure scripts in each package's host subdirectory.
+
+The first approach is generally simpler. However some of the
+package-specific code requires special installation, for example a
+program may have to be installed suid root so that it has the right
+privileges to access hardware, and hence the "make install" step has
+to be run by the superuser. Also some of the package-specific code is
+rather specialized and may be of no interest to many users. For
+example, the USB testing code is only useful when developing
+USB-based applications. Hence some users may prefer the second
+approach, building just the generic code and a subset of the
+package-specific code.
+
+It is necessary to use a separate build tree rather than build
+directly in the source tree. This is enforced by the configure scripts.
+
+  $ mkdir build
+  $ cd build
+
+The next step is to run the desired configure script. To build all
+the host-side software this means the toplevel configure script:
+
+  $ <path>/configure <args>
+
+Alternatively to build just the generic host-side software, use the
+configure script in the host subdirectory.
+
+  $ mkdir host
+  $ cd host
+  $ <path>/host/configure <args>
+
+Or, to build just one package's host-side code:
+
+  $ mkdir -p packages/io/usb/slave/current/host
+  $ cd packages/io/usb/slave/current/host
+  $ <path>/packages/io/usb/slave/current/host/configure <args>
+
+(It is not actually necessary to use the same directory structure in
+the build tree as in the source tree, but doing so can avoid
+confusion). 
+  
+A list of all the command-line options can be obtained by running
+"configure --help". The most important ones are as follows:
+
+1) --prefix. This can be used to specify the location of the install
+   tree, defaulting to /usr/local, so the ecosconfig program ends up
+   in /usr/local/bin/ecosconfig and the CDL library ends up in
+   /usr/local/lib/libcdl.a. If an alternative location is preferred
+   this can be specified with --prefix, for example:
+
+   $ <path>/configure --prefix=/usr/local/ecos <args>
+
+2) --enable-debug. By default all assertions and tracing are disabled.
+   When debugging any of the generic host-side software these should
+   be enabled. Some package-specific code may not have any extra
+   debug support, in which case --enable-debug would be ignored.
+
+   $ <path>/configure --enable-debug
+
+   It is also possible to control most of the assertion and tracing
+   macros at a finer grain. This is intended mainly for use by the
+   developers.
+
+   --disable-asserts        disable all assertions
+   --disable-preconditions  disable a subset of the assertions
+   --disable-postconditions disable a subset of the assertions
+   --disable-invariants     disable a subset of the assertions
+   --disable-loopinvariants disable a subset of the assertions
+   --disable-tracing        disable tracing
+   --disable-fntracing      disable function entry/exit tracing
+
+3) --with-tcl=<path>
+   --with-tcl-header=<path>
+   --with-tcl-lib=<path>
+   --with-tcl-version=<number>
+
+   The host-side tools have a dependency on Tcl, which is not supplied
+   with the sources because many people will already have a suitable
+   installation. Specifically it is necessary to have the header file
+   tcl.h and appropriate libraries such that -ltcl will work - this
+   can involve either static or shared libraries.
+
+   By default the configure script will assume that there is a
+   suitable Tcl installation in the install location, so if there is
+   no --prefix argument then it will look for /usr/local/include/tcl.h
+   and it will add -L/usr/local/lib to the library search path. If
+   Tcl is installed elsewhere then this can be specified with a
+   --with-tcl option. For example, if the default installation in
+   /usr should be used then the following configure option is
+   appropriate:
+
+   $ <path>/configure --with-tcl=/usr <args>
+
+   If the Tcl libraries and Tcl headers are installed in different
+   locations, such as when a separate --prefix and --exec-prefix are
+   used, the --with-tcl-header and --with-tcl-lib options can be used
+   to specify both location. The configure script will expect to find
+   <tcl-header-dir>/include/tcl.h and <tcl-lib-dir>/lib/tclConfig.sh.
+   The --with-tcl option has precedence and if used will override the
+   --with-tcl-header and --with-tcl-lib options.
+
+   It is possible to have multiple versions of Tcl installed, for
+   example libtcl8.0.a, libtcl8.1.a, and so on. Typically linking with
+   -ltcl will result in the latest version being used. It is possible
+   to specify a different version using --with-tcl-version, e.g.:
+
+   $ <path>configure --with-tcl=/usr/local/scriptics --with-tcl-version=8.1 <args>
+
+Following the configure step the build tree should be set up
+correctly. All that remains is the actual build and install:
+
+   $ make
+   $ make install
+
+This should result in an ecosconfig executable, plus appropriate
+libraries and header files. If the install prefix is a system
+location, for example /usr/local/, then "make install" will normally
+require root privileges. Also some of the package-specific software
+has special installation requirements, for example programs that need
+to be installed suid root, and this will also need root privileges.
+
+
+Installing under Cygwin
+-----------------------
+
+Installing under cygwin requires essentially the same steps as
+under Linux. It is more likely that a suitable --prefix option will
+have to be used, and that the location of the Tcl installation needs
+to be specified with --with-tcl. However appropriate use of cygwin
+mount points may avoid some of these problems. If the full path to
+the configure script contains spaces, then the short form of the path
+should be used when invoking configure.
+
+One issue to be aware of is the naming convention for the Tcl library.
+On a Unix system this will typically be called libtcl8.3.a (adjusted
+according to the version number), with a symbolic link from libtcl.a
+to the most recent version. Under cygwin the equivalent library is
+called libtcl80.a, and symbolic links are not used. For a standard
+cygwin installation the configure script knows how to pick up the
+appropriate library, but if a more recent version of Tcl has been
+installed then due care has to be taken with the --with-tcl-version
+option.
+
+
+Installing with Visual C++
+--------------------------
+
+Under Windows it is possible to build the generic host-side software
+(infra, libcdl and ecosconfig) with Visual C++ but this is deprecated.
+Building with g++ under cygwin is preferred.
+
+It is still necessary to run the configure script and a suitable make
+utility. That requires a shell and a Unix-like environment, as
+provided by cygwin. The Visual C++ compiler cl.exe needs to be on the
+shell's search path, and some environment variables such as INCLUDE
+and LIB may need to be set to point at the Visual C++ installation -
+the details may vary depending on the version of the compiler. Then
+the configure command should be run like this:
+
+  $ CC=cl CXX=cl <path>/host/configure <args>
+
+Note that the path should be a cygwin path: cygwin mount points are
+accepted and forward slashes should be used. The various configure
+scripts now detect that Visual C++ should be used, and adapt
+accordingly.
+
+Depending on what cygwin mount points are set up, /usr/local may or
+may not be an appropriate install location for VC++ applications.
+If not, the install location should be specified with --prefix:
+
+  $ CC=cl CXX=cl <path>/configure --prefix=<install-path> <args>
+
+It is also necessary to use the right version of Tcl. For a VC++ build
+the cygwin release of Tcl should not be used. Instead a suitable
+prebuilt Tcl package can be obtained from http://www.scriptics.com/.
+It is necessary to tell the configure script where this has been
+installed, for example:
+
+  $ CC=cl CXX=cl <path>/configure --prefix=<install-path> \
+    --with-tcl=/cygdrive/d/local/scriptics/Tcl/tcl8.1 <args>
+
+The library name will be of the form tcl81.lib, and there will not be
+a symbolic link from tcl.lib to the appropriate version. It will be
+necessary to specify the Tcl version explicitly since the default
+version is currently 8.0.
+
+  $ CC=cl CXX=cl <path>/configure --prefix=<install-path> \
+    --with-tcl=/d/local/scriptics/Tcl/tcl8.1 --with-tcl-version=81 <args>
+
+Following a successful configure, the tools can be built and installed
+in the normal fashion:
+
+  $ make
+  $ make install
+
+
+More Information
+================
+
+Please see the eCos web site, http://sources.redhat.com/ecos/, for
+further details. This includes the FAQ, a form for reporting problems,
+and details of the various mailing lists
+(http://sources.redhat.com/ecos/intouch.html) At the time of writing
+there are no separate mailing lists for the eCos host-side sources,
+the main mailing list ecos-discuss@sources.redhat.com should be used
+instead.
+
+//####COPYRIGHTBEGIN####
+//                                                                          
+//----------------------------------------------------------------------------
+// Copyright (C) 2002 Bart Veer
+// Copyright (C) 2000, 2001 Red Hat, Inc.
+//
+// This file is part of the eCos host tools.
+//
+// This program is free software; you can redistribute it and/or modify it 
+// under the terms of the GNU General Public License as published by the Free 
+// Software Foundation; either version 2 of the License, or (at your option) 
+// any later version.
+// 
+// This program is distributed in the hope that it will be useful, but WITHOUT 
+// ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
+// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for 
+// more details.
+// 
+// You should have received a copy of the GNU General Public License along with
+// this program; if not, write to the Free Software Foundation, Inc., 
+// 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+//
+// ----------------------------------------------------------------------------
+//                                                                          
+//####COPYRIGHTEND####
deleted file mode 100644
--- a/host/README
+++ /dev/null
@@ -1,383 +0,0 @@
-		eCos Host-side Software
-		=======================
-
-This directory contains the eCos host-side sources. This includes
-libcdl, the CDL library which underlies the whole eCos configuration
-system, and both the command-line and graphical configuration tools.
-
-The eCos host-side software is free software, released under the GNU
-General Public License. See the file COPYING for further details.
-
-
-Contents
-========
-
-The host-side sources include the following:
-
-infra/
-    This is an implementation of the eCos infrastructure that can be
-    used on the host-side, and provides assertion, tracing and
-    testcase support.
-
-    NOTE: the eCos infrastructure facilities are not especially
-    well-suited to host-side development, in particular they are not
-    C++-oriented. There are plans to remove the current infrastructure
-    completely and replace it with something more suitable. People
-    planning new projects should be aware of this, and may wish to
-    avoid using the current infrastructure.
-
-libcdl/
-    The CDL library lies at the heart of the eCos configuration system.    
-
-tools/configtool/
-    The sources to the various configuration tools can be found here.
-
-tools/configtool/standalone/common/
-    Contains the command line ecosconfig tool.
-
-tools/configtool/common/common/
-    Contains sources related to makefile generation.
-
-tools/configtool/common/win32/
-tools/configtool/standalone/win32/
-    Contains sources for the MFC-based, Windows-only graphical configuration
-    tool.
-
-tools/configtool/standalone/wxwin/
-    Contains sources for the wxWindows-based, Linux and Windows graphical
-    configuration tool.
-
-There are various other sub-directories related to the admin tool,
-testing support, and so on.
-
-It should be noted that the eCos host-side software is still
-undergoing rapid development, and the sources are subject to change
-and reorganization at any time.    
-
-Much of the code is cross-platform. The obvious exception is the
-original, MFC-based graphical configuration tool which can only
-be built for Windows hosts and requires Visual C++. It should be
-possible to build the underlying libraries and the command-line
-configuration tool using gcc/g++ on any Unix platform.
-
-A combined Unix and Windows version of the graphical
-configuration tool, built using the wxWindows GUI toolkit, is
-under development and has its own ReadMe in
-tools/configtool/standalone/wxwin. Any further reference to the
-graphical configuration tool in this document refers to the
-original MFC-based version.
-
-More Information
-================
-
-Please see the eCos web site, http://sourceware.cygnus.com/ecos/, for
-further details. This includes the FAQ, a form for reporting problems,
-and details of the various mailing lists
-(http://sourceware.cygnus.com/ecos/intouch.html)
-At the time of writing there are no separate mailing lists for the
-eCos host-side sources, the main mailing list
-ecos-discuss@sourceware.cygnus.com should be used instead.
-
-
-Installation
-============
-
-Test builds of the eCos host-side generally happen on the following
-platforms: Red Hat Linux 6.1 and later; Windows NT using cygwin 1.0 or
-later; and Windows NT using VC++ 6.0. The graphical configuration tool
-can only be built with VC++ and involves a Developer Studio project,
-see tools/configtool/standalone/win32/Configtool.dsw. The other
-software can be built using the conventional "configure/make/make
-install" steps. It should be noted that the eCos host-side software is
-not fully auto-confiscated, and some facilities like "make dist" will
-not work. Also, the existing DejaGnu-based testing facilities are
-minimal, only intended as a starting point, and may not work on all
-platforms.
-
-The eCos host-side software has a dependency on Tcl. This is not
-supplied with the sources, because many users will already have a
-suitable installation. Any release of Tcl from 8.0 onwards should be
-usable. There are some configure command-line options related to the
-Tcl installation, as described below.
-
-The instructions for installing under Linux are given first.
-Installation on other platforms is very similar, so only the
-differences will be noted.
-
-Installing on Linux
-===================
-
-It is strongly recommended that a separate build tree is used, as
-opposed to building directly in the source tree. The latter has not
-been tested and, given some of the build steps, may not work very
-well.
-
-  $ mkdir build
-  $ cd build
-
-The next step is to run the toplevel configure script, in other words
-the configure script in the same directory as this README file. This
-will automatically recurse into the various subdirectories for the
-infrastructure, libcdl, and so on. Note that all of the host-side
-software needs to be configured and built: it is not possible to
-invoke just the configure script for the ecosconfig tool and build
-just that tool, because there are dependencies on other parts of the
-host-side code.
-
-  $ <path>/configure <args>
-
-A list of the all the command-line options can be obtained by running
-"configure --help". The most important ones are as follows:
-
-1) --prefix. This can be used to specify the location of the install
-   tree, defaulting to /usr/local, so the ecosconfig program ends up
-   in /usr/local/bin/ecosconfig and the CDL library ends up in
-   /usr/local/lib/libcdl.a. If an alternative location is preferred
-   this can be specified with --prefix, for example:
-
-   $ <path>/configure --prefix=/usr/local/ecos <args>
-
-2) --enable-debug. By default all assertions and tracing are disabled.
-   When debugging any of the host-side software these must be enabled.
-
-   $ <path>/configure --enable-debug
-
-   It is also possible to control most of the assertion and tracing
-   macros at a finer grain. This is likely to be useful only to the
-   main developers:
-
-   --disable-asserts        disable all assertions
-   --disable-preconditions  disable a subset of the assertions
-   --disable-postconditions disable a subset of the assertions
-   --disable-invariants     disable a subset of the assertions
-   --disable-loopinvariants disable a subset of the assertions
-   --disable-tracing        disable tracing
-   --disable-fntracing      disable function entry/exit tracing
-
-3) --with-tcl=<path>, --with-tcl-header=<path>, --with-tcl-lib=<path>
-   and --with-tcl-version=<number>
-
-   The host-side tools have a dependency on Tcl, which is not supplied
-   with the sources because many people will already have a suitable
-   installation. Specifically it is necessary to have the header file
-   tcl.h and appropriate libraries such that -ltcl will work - this
-   can involve either static or shared libraries.
-
-   By default the configure script will assume that there is a
-   suitable Tcl installation in the install location, so if there is
-   no --prefix argument then it will look for /usr/local/include/tcl.h
-   and it will add -L/usr/local/lib to the library search path. If
-   Tcl is installed elsewhere then this can be specified with a
-   --with-tcl option. For example, if the default installation in
-   /usr should be used then the following configure option is
-   appropriate:
-
-   $ <path>/configure --with-tcl=/usr <args>
-
-   If the Tcl libraries and Tcl headers are installed in different
-   locations, such as when a seperate --prefix and --exec-prefix are
-   used, the --with-tcl-header and --with-tcl-lib options can be used
-   to specify both location.  The configure will expect to find
-   <tcl-header-dir>/include/tcl.h and <tcl-lib-dir>/lib/tclConfig.sh.
-   The --with-tcl option has precedence and if used will override the
-   --with-tcl-header and --with-tcl-lib options.
-
-   It is possible to have multiple versions of Tcl installed, for
-   example libtcl8.0.a, libtcl8.1.a, and so on. Typically linking with
-   -ltcl will result in the latest version being used. It is possible
-   to specify a different version using --with-tcl-version, e.g.:
-
-   $ <path>configure --with-tcl=/usr/local/scriptics --with-tcl-version=8.1 <args>
-
-Following the configure step the build tree should be set up
-correctly. All that remains is the actual build and install:
-
-   $ make
-   $ make install
-
-This should result in an ecosconfig executable, plus appropriate
-libraries and header files.   
-   
-
-Installing on cygwin
-====================
-
-Installing under cygwin requires essentially the same steps as
-under Linux. It is more likely that a suitable --prefix option will
-have to be used, and that the location of the Tcl installation needs
-to be specified with --with-tcl. However appropriate use of cygwin
-mount points may avoid some of these problems. If the full path to
-the configure script contains spaces, then the short form of the path
-should be used when invoking configure.
-
-One issue to be aware of is the naming convention for the Tcl library.
-On a Unix system this will typically be called libtcl8.0.a (adjusted
-according to the version number), with a symbolic link from libtcl.a
-to the most recent version. Under cygwin the equivalent library is
-called libtcl80.a, and symbolic links are not used. For a standard
-cygwin 1.0 installation the configure script knows how to pick up the
-appropriate library, but if a more recent version of Tcl has been
-installed then due care has to be taken with the --with-tcl-version
-option. 
-
-
-Installing on NT with VC++ (using Visual Studio)
-================================================
-
-It is possible to build both the graphical configuration tool and the
-ecosconfig command line tool using a Developer Studio project,
-tools/ecosconfig/standalone/win32/Configtool.dsw
-
-Even if building the host tools from Visual Studio, it is still 
-necessary to install Cygwin and Tcl 8.x. Additionally, there is a
-dependency on either the Microsoft Platform SDK or the Microsoft
-HTML Help Workshop.
-
-The latter is available at:
-http://msdn.microsoft.com/library/tools/htmlhelp/wkshp/download.htm
-
-To prepare the machine for the build, it is necessary to:
-
-1) Set the TCLHOME environment variable to the root of the Tcl installation.
-(For example, TCLHOME=C:\tcl) This can be set from the Enviroment Variables
-dialog on the Advanced tab of the System Properties dialog.
-
-2) It is also necessary to add several directories to Visual Studio's default
-file search paths. This is set from the Directories tab in the Options menu.
-
-The following entries will need to be added (full paths are shown for clarity,
-the actual path may be different):
-
-	a) Executable Files
-		c:\cygwin\bin
-	b) Include Files
-		c:\tcl\include
-		c:\program files\microsoft platform sdk\include _OR_
-		c:\program files\html help workshop\include
-	c) Library Files
-		c:\tcl\lib
-		c:\program files\microsoft platform sdk\lib _OR_
-		c:\program files\html help workshop\lib
-
-3) The build process as setup by default in the sources available from CVS is
-setup to build the host tools on the DOS v:\ drive. If this drive doesn't exist,
-it may be preferable to do a "subst v:\ c:\temp" command from a Windows command 
-shell. This will effectively create a virtual disk which is located at c:\temp,
-and the build process will place all intermediate and build files in this location.
-(Alternatively, it is possible to go through the project settings in Visual Studio
-and adjust the drive letters manually.)
-
-4) If you have installed a version of Tcl other than version 8.2, it will be necessary
-to change the names of libraries linked with the projects. This can be done by:
-
-a) Selecting "Settings..." on the ChangeLog file in the cdl project in the
-Configtool workspace, you will see the custom build step for the project.
-At the end of the first line of the custom build step, there is an option
---with-tcl_version=82. Change this value (82) to correspond to the version of Tcl
-installed on the machine.
-
-b) Selecting "Settings..." on the Configtool project in the workspace, you should
-go to the Link tab in the right-hand pane. In this pane you will see a line listing
-all the Libraries with which the project is being linked. Change the tcl82.lib entry
-to the name appropriate for the version of Tcl installed.
-
-(NOTE: These settings must be applied to all configurations you intend to build 
-separately. The eCos host tools as shipped by RedHat are built using the 
-"Win32 ANSI Release" Configuration. If you build the "Win32 Release" Configuration,
-you will also need to have the Unicode version of the MFC libraries and DLLs.)
-
-5) Click "Build... (F7)". The compiled binaries will be located in the Configtool
-folder on the V:\ drive.
-
-
-NOTES:
-
-1) When using WinCVS, make sure to use the default Windows mode to get the tools.
-Using UNIX mode will break the Visual Studio project files and you won't be able
-to open them. (It is preferable, in general, to use Windows mode for all eCos files.)
-
-2) There will be many warnings related to STL header compilation. These are benign.
-There are also some warnings related to missing help files at the beginning of the
-Configtool project compilation. These can also be ignored.
-
-3) To build the other Win32 projects in the host tools, it may be necessary to repeat
-step 4.b) above. (Again, this depends on which version of Tcl is in use.)
-
-
-Installing on NT with VC++ (using Cygwin)
-=========================================
-
-It is also possible to build the command line tool and the various
-libraries using the configure script. At the time of writing the
-graphical configuration tool cannot yet be built that way. This still
-requires a cygwin installation because it needs the bash shell and GNU
-make. First, it is necessary to tell the configure script to use a
-compiler other than gcc:
-
-  $ mkdir build
-  $ cd build
-  $ CC=cl CXX=cl <path>/configure <args>
-
-The configure script will do the right thing if VC++ is specified in
-this way.
-
-It is likely that /usr/local will be an inappropriate install location
-for VC++ applications, so an alternative prefix needs to be specified:
-
-  $ CC=cl CXX=cl <path>/configure --prefix=<install-path> <args>
-
-Note that the install path should be a cygwin path, i.e. cygwin mount
-points are accepted and forward slashes should be used.
-  
-It is also necessary to use the right version of Tcl. For a VC++ build
-the cygwin release of Tcl should not be used. Instead a suitable
-prebuilt Tcl package can be obtained from http://www.scriptics.com/.
-It is necessary to tell the configure script where this has been
-installed, for example:
-
-  $ CC=cl CXX=cl <path>/configure --prefix=<install-path> \
-    --with-tcl=/d/local/scriptics/Tcl/tcl8.1 <args>
-
-The library name will be of the form tcl81.lib, and there will not be
-a symbolic link from tcl.lib to the appropriate version. Typically it
-will be necessary to specify the Tcl version explicitly:    
-
-  $ CC=cl CXX=cl <path>/configure --prefix=<install-path> \
-    --with-tcl=/d/local/scriptics/Tcl/tcl8.1 --with-tcl-version=81 <args>
-
-Following a successful configure, the tools can be built and installed
-in the normal fashion:
-
-  $ make
-  $ make install
-
-This assumes that the cl.exe executable is on the shell's search path,
-and that appropriate environment variables such as INCLUDE and LIB are
-set up correctly. The VC++ documentation should be consulted for
-further information.
-  
-
-//####COPYRIGHTBEGIN####
-//                                                                          
-// ----------------------------------------------------------------------------
-// Copyright (C) 2000, 2001 Red Hat, Inc.
-//
-// This file is part of the eCos host tools.
-//
-// This program is free software; you can redistribute it and/or modify it 
-// under the terms of the GNU General Public License as published by the Free 
-// Software Foundation; either version 2 of the License, or (at your option) 
-// any later version.
-// 
-// This program is distributed in the hope that it will be useful, but WITHOUT 
-// ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
-// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for 
-// more details.
-// 
-// You should have received a copy of the GNU General Public License along with
-// this program; if not, write to the Free Software Foundation, Inc., 
-// 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-//
-// ----------------------------------------------------------------------------
-//                                                                          
-//####COPYRIGHTEND####
--- a/host/tools/configtool/ChangeLog
+++ b/host/tools/configtool/ChangeLog
@@ -1,3 +1,8 @@
+2002-08-12  Bart Veer  <bartv@ecoscentric.com>
+
+	* standalone/win32/ReadMe:
+	Move build instructions here from the toplevel
+
 2002-08-03  Bart Veer  <bartv@ecoscentric.com>
 
 	* standalone/common/Makefile.am, configure.in, acinclude.m4:
new file mode 100644
--- /dev/null
+++ b/host/tools/configtool/standalone/win32/ReadMe
@@ -0,0 +1,90 @@
+	Building the VC++ Windows Configuration Tool
+	============================================
+
+NOTE: this tool is no longer supported. Users wanting a graphical
+configuration tool under Windows should instead consider the
+wxWindows-based tool, ../wxwin/ReadMe.
+
+The graphical configuration tool can be built using a Developer Studio
+project, tools/ecosconfig/standalone/win32/Configtool.dsw
+Even if building the host tools from Visual Studio, it is still
+necessary to install Cygwin and Tcl 8.x. Additionally, there is a
+dependency on either the Microsoft Platform SDK or the Microsoft HTML
+Help Workshop. The latter is available at:
+http://msdn.microsoft.com/library/tools/htmlhelp/wkshp/download.htm
+
+To prepare the machine for the build, it is necessary to:
+
+1) Set the TCLHOME environment variable to the root of the Tcl
+installation. (For example, TCLHOME=C:\tcl) This can be set from the
+Enviroment Variables dialog on the Advanced tab of the System
+Properties dialog.
+
+2) It is also necessary to add several directories to Visual Studio's
+default file search paths. This is set from the Directories tab in the
+Options menu.
+
+The following entries will need to be added (full paths are shown for
+clarity, the actual path may be different):
+
+	a) Executable Files
+		c:\cygwin\bin
+	b) Include Files
+		c:\tcl\include
+		c:\program files\microsoft platform sdk\include _OR_
+		c:\program files\html help workshop\include
+	c) Library Files
+		c:\tcl\lib
+		c:\program files\microsoft platform sdk\lib _OR_
+		c:\program files\html help workshop\lib
+
+3) The build process as setup by default in the sources available from
+CVS is setup to build the host tools on the DOS v:\ drive. If this
+drive doesn't exist, it may be preferable to do a "subst v:\ c:\temp"
+command from a Windows command shell. This will effectively create a
+virtual disk which is located at c:\temp, and the build process will
+place all intermediate and build files in this location.
+(Alternatively, it is possible to go through the project settings in
+Visual Studio and adjust the drive letters manually.)
+
+4) If you have installed a version of Tcl other than version 8.2, it
+will be necessary to change the names of libraries linked with the
+projects. This can be done by:
+
+a) Selecting "Settings..." on the ChangeLog file in the cdl project in
+the Configtool workspace, you will see the custom build step for the
+project. At the end of the first line of the custom build step, there
+is an option --with-tcl_version=82. Change this value (82) to
+correspond to the version of Tcl installed on the machine.
+
+b) Selecting "Settings..." on the Configtool project in the workspace,
+you should go to the Link tab in the right-hand pane. In this pane you
+will see a line listing all the Libraries with which the project is
+being linked. Change the tcl82.lib entry to the name appropriate for
+the version of Tcl installed.
+
+(NOTE: These settings must be applied to all configurations you intend
+to build separately. The eCos host tools as shipped by RedHat were
+built using the "Win32 ANSI Release" Configuration. If you build the
+"Win32 Release" Configuration, you will also need to have the Unicode
+version of the MFC libraries and DLLs.)
+
+5) Click "Build... (F7)". The compiled binaries will be located in the
+Configtool folder on the V:\ drive.
+
+
+NOTES:
+
+1) When using WinCVS, make sure to use the default Windows mode to get
+the tools. Using UNIX mode will break the Visual Studio project files
+and you won't be able to open them. (It is preferable, in general, to
+use Windows mode for all eCos files.)
+
+2) There will be many warnings related to STL header compilation.
+These are benign. There are also some warnings related to missing help
+files at the beginning of the Configtool project compilation. These
+can also be ignored.
+
+3) To build the other Win32 projects in the host tools, it may be
+necessary to repeat step 4.b) above. (Again, this depends on which
+version of Tcl is in use.)