|
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 Copyright (C) 2002, 2003 Bart Veer
|
|
dnl Copyright (C) 1998, 1999, 2000, 2001 Red Hat, Inc.
|
|
dnl
|
|
dnl This file is part of the eCos host tools.
|
|
dnl
|
|
dnl This program is free software; you can redistribute it and/or modify it
|
|
dnl under the terms of the GNU General Public License as published by the Free
|
|
dnl Software Foundation; either version 2 of the License, or (at your option)
|
|
dnl any later version.
|
|
dnl
|
|
dnl This program is distributed in the hope that it will be useful, but WITHOUT
|
|
dnl ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
dnl FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
dnl more details.
|
|
dnl
|
|
dnl You should have received a copy of the GNU General Public License along with
|
|
dnl this program; if not, write to the Free Software Foundation, Inc.,
|
|
dnl 59 Temple Place - Suite 330, Boston, MA 02111-1307, 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
|
|
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
|
|
SUBDIRS="host"
|
|
elif test -f "${srcdir}/tools/src/configure" ; then
|
|
SUBDIRS="tools/src"
|
|
else
|
|
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.
|
|
|
|
PKGHOSTDIRS=""
|
|
FOUND_CONFIGURES=""
|
|
FOUND_CONFIGURES="${FOUND_CONFIGURES} ${srcdir}/packages/*/*/host/configure"
|
|
FOUND_CONFIGURES="${FOUND_CONFIGURES} ${srcdir}/packages/*/*/*/host/configure"
|
|
FOUND_CONFIGURES="${FOUND_CONFIGURES} ${srcdir}/packages/*/*/*/*/host/configure"
|
|
FOUND_CONFIGURES="${FOUND_CONFIGURES} ${srcdir}/packages/*/*/*/*/*/host/configure"
|
|
FOUND_CONFIGURES="${FOUND_CONFIGURES} ${srcdir}/packages/*/*/*/*/*/*/host/configure"
|
|
for configure in ${FOUND_CONFIGURES}; 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}/::"`
|
|
PKGHOSTDIRS="${PKGHOSTDIRS} ${hostdir}"
|
|
fi
|
|
done
|
|
|
|
SUBDIRS="${SUBDIRS} ${PKGHOSTDIRS}"
|
|
|
|
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} ${top_srcdir}/acsupport/mkinstalldirs ${REQUIRED_DIRS}],REQUIRED_DIRS="${SUBDIRS}")
|
|
|
|
AC_SUBST(SUBDIRS)
|
|
AC_CONFIG_SUBDIRS(${SUBDIRS})
|
|
AC_OUTPUT(Makefile)
|
|
|
