Added the OS files

1 files changed, 226 insertions, 0 deletions

diff --git a/ecos/configure.in b/ecos/configure.in
new file mode 100644
index 0000000..48e50e1
--- /dev/null
+++ b/ecos/configure.in
@@ -0,0 +1,226 @@
+dnl Process this file with autoconf to produce a configure script.
+dnl ====================================================================
+dnl
+dnl     configure.in
+dnl
+dnl     Top-level configure script for eCos software.
+dnl
+dnl ====================================================================
+dnl ####ECOSHOSTGPLCOPYRIGHTBEGIN####                                       
+dnl -------------------------------------------                             
+dnl This file is part of the eCos host tools.                               
+dnl Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+dnl
+dnl This program is free software; you can redistribute it and/or modify    
+dnl it under the terms of the GNU General Public License as published by    
+dnl the Free Software Foundation; either version 2 or (at your option) any  
+dnl later version.                                                          
+dnl
+dnl This program is distributed in the hope that it will be useful, but     
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of              
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU       
+dnl General Public License for more details.                                
+dnl
+dnl You should have received a copy of the GNU General Public License       
+dnl along with this program; if not, write to the                           
+dnl Free Software Foundation, Inc., 51 Franklin Street,                     
+dnl Fifth Floor, Boston, MA  02110-1301, USA.                               
+dnl -------------------------------------------                             
+dnl ####ECOSHOSTGPLCOPYRIGHTEND####                                         
+dnl ====================================================================
+dnl#####DESCRIPTIONBEGIN####
+dnl
+dnl Author(s):	bartv
+dnl Contact(s):	bartv
+dnl Date:	1998/12/17
+dnl Version:	0.01
+dnl
+dnl####DESCRIPTIONEND####
+dnl ====================================================================
+
+dnl eCos is a componentized architecture for deeply embedded systems.
+dnl It requires a very different configuration system from typical
+dnl autoconfiscated software such as the various GNU packages.
+dnl
+dnl The main eCos host-side software is autoconfiscated to some extent,
+dnl in that the usual sequence of "configure;make;make install" will
+dnl work under the right conditions. However it does not conform to
+dnl the GNU coding standards in numerous ways, for example "make dist"
+dnl will not work. The main eCos host-side software lives in the
+dnl "host" subdirectory, and is built unconditionally.
+dnl
+dnl The eCos target-side software lives in the "packages" subdirectory,
+dnl and is organized in numerous subdirectories corresponding to different
+dnl packages and potentially different versions of each package. In the
+dnl master repository managed by CVS there will only be one version of
+dnl each package, "current", which simplifies things somewhat. Other
+dnl repositories will not be quite so straightforward and require a
+dnl suitable administration tool.
+dnl
+dnl The various eCos packages are not currently auto-confiscated.
+dnl In particular building eCos requires the use of eCos configuration
+dnl technology, not autoconf - there is simply no good way of handling
+dnl a system as highly configurable as eCos using a few command-line
+dnl options passed to "configure". There would also be serious confusion
+dnl between host and target, especially when e.g. cross-compiling the
+dnl host tools. However a possible future enhancement
+dnl would involve making eCos releases via configure and make, thus
+dnl allowing for a release process that combines building the various
+dnl host-side tools such as gcc with creating eCos epk's for the various
+dnl packages.
+dnl
+dnl A complication is that some of the eCos target-side packages also
+dnl contain package-specific host-side support. For example the
+dnl Linux synthetic target support uses special host-side software
+dnl to provide I/O facilities: the architectural HAL package provdes
+dnl generic support, the synthetic ethernet package extends this
+dnl with ethernet support, and so on. Such package-specific host-side
+dnl software does not belong in the main host subdirectory, that
+dnl would make it very difficult to distribute new packages or
+dnl new versions of a package. However keeping the code with the
+dnl various packages makes building more complicated.
+dnl
+dnl   1) if the entire repository is managed by CVS or anoncvs, this
+dnl      configure script will search the packages tree for any packages
+dnl      that have host-side software that needs to be built -
+dnl      specifically, that have a file "configure" inside a "host"
+dnl      subdirectory in a version of a package.
+dnl
+dnl   2) if instead the repository contains additional packages
+dnl      installed as epk's and managed by an administration tool then
+dnl	 it is the responsibility of that tool to let the users build
+dnl      and rebuild the host-side software as required, for whichever
+dnl      host platform or platforms are being used. In other words
+dnl      it is the responsibility of the admin tool to create a
+dnl      suitable build directory and run "configure; make; make install",
+dnl      usually as part of the installation process. Note that several
+dnl	 versions of a package may be installed, and it is the
+dnl	 responsibility of each package to take this into account
+dnl      (although the configure macros are aware of this to some extent,
+dnl      and will e.g. generate suitable install directory names).	 	 
+dnl      Also note that the top-level configure script will not pick
+dnl      up such packages because they will be versioned, i.e. the
+dnl      test for current/host/configure will fail because the
+dnl      version will not be "current".
+dnl
+dnl   3) as a special case it may be desirable to ship pre-built binaries
+dnl      of some of the package-specific software. It is not clear
+dnl	 just what would be the best way of shipping these - putting
+dnl      them into the epk's would not be quite right because that would
+dnl      make the epk's host-specific rather than generic.
+dnl
+dnl There is an unresolved problem with possible dependencies between
+dnl packages, if e.g. the host-side of the synthetic ethernet package could
+dnl only be built after the architectural synthetic target package.
+
+dnl Some of the eCos documentation is generic and lives in the "doc"
+dnl subdirectory. Other eCos documentation is package-specific and lives
+dnl in the appropriate package directory. At present there is no support
+dnl for building the documentation via configure and make, but such
+dnl support may be added in future.
+dnl
+dnl There is a subdirectory acsupport containing various files such
+dnl as config.guess and install.sh that are common. This also contains
+dnl an acinclude.m4 file with various macros that are useful for
+dnl eCos.
+
+dnl Generic initialization.
+AC_INIT(acsupport/config.guess)
+AC_CONFIG_AUX_DIR(acsupport)
+AC_CANONICAL_HOST
+AM_INIT_AUTOMAKE(eCos,2.0,0)
+AM_MAINTAINER_MODE
+
+dnl Detect attempts at cross-compilation. Usually this is the result
+dnl of somebody failing to read the documentation or the README.host
+dnl file.
+if test "${target_alias}x" != "x" ; then
+  AC_MSG_ERROR("
+================================================================
+You have specified a target ${target_alias}.
+This configure script is for building the eCos host-side support
+tools which are independent of the target architecture. It is not
+used for building eCos itself.
+
+If your intention is to build eCos itself then you should first
+read the relevant documentation starting with the User's Guide.
+
+If your intention is to rebuild the host-side support tools then
+there is no need to specify --target.
+
+If your intention is to cross-compile the host-side support tools
+then you should be using --host instead of --target.
+================================================================
+")
+fi  
+
+dnl Make sure the source and build trees are kept separate.
+ECOS_CHECK_BUILD_ne_SRC
+
+dnl Nothing actually gets built in this directory, so there should be no
+dnl need to worry about compiler flags etc. Instead, the problem is
+dnl figuring out what should actually get built.
+dnl
+dnl  1) the host subdirectory should always get built, if it exists.
+dnl     With the 2.0 release system the directory gets moved to
+dnl     tools/src
+		     
+if test -f "${srcdir}/host/configure" ; then
+   ecos_subdirs="host"
+elif test -f "${srcdir}/tools/src/configure" ; then
+   ecos_subdirs="tools/src"
+else   
+   ecos_subdirs=""
+fi   
+
+dnl  2) any package which has a configure script in a
+dnl     current/host subdirectory should also get built.
+dnl
+dnl     Searching the directory tree is currently done by shell globbing.
+dnl     Invoking "find" with suitable arguments might be quicker, but
+dnl     less portable. On some hosts there may be problems with environmental
+dnl     limits if too many packages provide host-side software.
+dnl
+dnl     Currently there is no ordering of packages, so e.g. a device
+dnl     driver's host-side support cannot depend on some HAL package
+dnl     because the latter may not have been built and installed yet.
+dnl     This is a good thing because packages are meant to be self-contained
+dnl     whenever possible. Interaction between packages is typically handled
+dnl     at the Tcl level at run-time, so there are no build-time complications.
+
+AC_MSG_NOTICE([searching for configure scripts in eCos packages'
+host subdirectories. This operation can take a long time.
+If running on Windows and the eCos repository is accessed
+over a network then it may take some hours.])
+ecos_hostdirs=""
+ecos_configure_scripts="${srcdir}/packages/*/*/host/configure"
+ecos_configure_scripts="${ecos_configure_scripts} ${srcdir}/packages/*/*/*/host/configure"
+ecos_configure_scripts="${ecos_configure_scripts} ${srcdir}/packages/*/*/*/*/host/configure"
+ecos_configure_scripts="${ecos_configure_scripts} ${srcdir}/packages/*/*/*/*/*/host/configure"
+ecos_configure_scripts="${ecos_configure_scripts} ${srcdir}/packages/*/*/*/*/*/*/host/configure"
+for configure in ${ecos_configure_scripts}; do
+    if test -f ${configure}; then
+        dnl A configure script has been found in the source tree.
+        dnl First turn it into a directory, then replace the absolute path
+        dnl with a relative one.
+        hostdir=`dirname ${configure}`
+        hostdir=`echo ${hostdir} | sed -e "s:^${srcdir}/::"`
+        ecos_hostdirs="${ecos_hostdirs} ${hostdir}"
+    fi
+done
+AC_MSG_NOTICE([found configure scripts in
+${ecos_hostdirs}])
+ecos_subdirs="${ecos_subdirs} ${ecos_hostdirs}"
+
+dnl Because the eCos directory layout does not conform to GNU conventions
+dnl it is necessary to create various levels of intermediate directories.
+dnl This happens via config.status, prior to the recursion into the
+dnl appropriate directories.
+AC_OUTPUT_COMMANDS([${CONFIG_SHELL-/bin/sh} ${ac_top_srcdir}/acsupport/mkinstalldirs ${REQUIRED_DIRS}],REQUIRED_DIRS="${ecos_subdirs}")
+
+dnl This causes warnings with current versions of configure which
+dnl want literal arguments. Since this script deliberately searches
+dnl for subdirectories there is no obvious way to eliminate those
+dnl warnings.
+AC_CONFIG_SUBDIRS(${ecos_subdirs})
+AC_OUTPUT(Makefile)