Files
rtems/configure.in

543 lines
16 KiB
Plaintext
Raw Normal View History

dnl Process this file with autoconf to produce a configure script.
dnl
dnl $Id$
AC_PREREQ(2.12)
AC_INIT(README)
Towards automake XI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This patch is the most scary of all proposals I've been mailing to you this week until now. It consists of 3 parts: 1. a patch 2. a perl script (acpolish) 3. a shell script wrapper to invoke the perl-script. The perl-script reads in each Makefile.in and modifies them ("polishes/beautifies" them :-). These modifications are not easy to describe: Basically, it hard-codes some automake Makefile-variables and rules into RTEMS autoconf-Makefile.ins (Note: autoconf vs. automake!!) and converts some settings/variables to configure scripts' requirements (Yes, plural). E.g. it adds the automake standard variables $top_builddir and $subdir, adds dependency rules for automatic re-generation of Makefiles from Makefile.in, adds support variables for relative paths to multiple configure scripts etc. The patch is a one-line patch to enable the support of the new features added by acpolish. The shell script is a wrapper which pokes around inside of the source tree for Makefile.ins and invokes acpolish on all autoconf-Makefile.ins. acpolish is designed to be able to run several times on the same Makefile.in and may once become a more general tool to convert RTEMS Makefile.in to automake. Therefore, I'd like to keep it inside of source tree. (e.g. as contrib/acpolish or c/update-tools/acpolish). However, it doesn't make sense to export it outside of RTEMS. To apply this: cd <source-tree> patch -p1 -E < <path-to-patch>/rtems-rc-19990318-1.diff tar xzvf <path-to>/rtems-rc-polish.tar.gz ./rtems-polish.sh ./autogen Note: The path contrib/acpolish is hard-coded into rtems-polish.sh, if you decide to put it in an alternative place, please modify rtems-polish.sh to reflect this change. Later: cvs rm make/rtems.cfg (It isn't used anymore) cvs add contrib cvs add contrib/acpolish cvs commit I've tested this intensively, but naturally I can't exclude bugs. Ralf. PS.: Most probably, this is the last "Towards automake" patch. The next one probably will be a real automake patch.
1999-03-19 22:27:02 +00:00
RTEMS_TOP(.)
dnl Checks for programs.
AC_PROG_MAKE_SET
AC_CANONICAL_SYSTEM
AC_ARG_WITH(cross-host,[ --with-cross-host=HOST host (cygnus)], \
host=$withval)
AC_ARG_ENABLE(gmake-print-directory, \
[ --enable-gmake-print-directory enable GNU Make's print directory], \
[case "${enableval}" in
1997-08-26 19:25:20 +00:00
yes) RTEMS_USE_OWN_PDIR=no ;;
no) RTEMS_USE_OWN_PDIR=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gmake-print-directory option) ;;
esac],[RTEMS_USE_OWN_PDIR=yes])
AC_ARG_ENABLE(multiprocessing, \
[ --enable-multiprocessing enable multiprocessing interface], \
[case "${enableval}" in
yes) RTEMS_HAS_MULTIPROCESSING=yes ;;
no) RTEMS_HAS_MULTIPROCESSING=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-multiprocessing option) ;;
esac],[RTEMS_HAS_MULTIPROCESSING=no])
AC_ARG_ENABLE(posix, \
[ --enable-posix enable posix interface], \
[case "${enableval}" in
yes) RTEMS_HAS_POSIX_API=yes ;;
no) RTEMS_HAS_POSIX_API=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-posix option) ;;
esac],[RTEMS_HAS_POSIX_API=yes])
AC_ARG_ENABLE(networking, \
[ --enable-networking enable TCP/IP stack], \
[case "${enableval}" in
yes) RTEMS_HAS_NETWORKING=yes ;;
no) RTEMS_HAS_NETWORKING=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-networking option) ;;
esac],[RTEMS_HAS_NETWORKING=yes])
1997-05-27 23:39:29 +00:00
AC_ARG_ENABLE(rdbg, \
[ --enable-rdbg enable remote debugger], \
[case "${enableval}" in
yes) RTEMS_HAS_RDBG=yes ;;
no) RTEMS_HAS_RDBG=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-rdbg option) ;;
esac],[RTEMS_HAS_RDBG=no])
AC_ARG_ENABLE(rtems-inlines, \
[ --enable-rtems-inlines enable RTEMS inline functions, the default (disable to use macros)], \
[case "${enableval}" in
yes) RTEMS_USE_MACROS=no ;;
no) RTEMS_USE_MACROS=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for disable-rtems-inlines option) ;;
esac],[RTEMS_USE_MACROS=no])
AC_ARG_ENABLE(cxx, \
[ --enable-cxx enable C++ support, and build the rtems++ library], \
[case "${enableval}" in
yes) RTEMS_HAS_CPLUSPLUS=yes ;;
no) RTEMS_HAS_CPLUSPLUS=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-cxx option) ;;
esac], [RTEMS_HAS_CPLUSPLUS=no])
AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in
yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;
1997-12-22 20:33:55 +00:00
esac],[RTEMS_USE_GCC272=no])
AC_ARG_ENABLE(libcdir, \
[ --enable-libcdir=directory set the directory for the C library], \
[ RTEMS_LIBC_DIR="${enableval}" ; \
test -d ${enableval} || AC_MSG_ERROR("$enableval is not a directory" ) ] )
AC_ARG_ENABLE(bare-cpu-cflags,
[ --enable-bare-cpu-cflags \
specify a particular cpu cflag (bare bsp specific)],
[case "${enableval}" in
no) BARE_CPU_CFLAGS="" ;;
*) BARE_CPU_CFLAGS="${enableval}" ;;
esac],
[BARE_CPU_CFLAGS=""])
AC_ARG_ENABLE(bare-cpu-model,
[ --enable-bare-cpu-model \
specify a particular cpu model (bare bsp specific)],
[case "${enableval}" in
no) BARE_CPU_MODEL="" ;;
*) BARE_CPU_MODEL="${enableval}" ;;
esac],
[BARE_CPU_MODEL=""])
RTEMS_PREFIX=${target_cpu}-${target_vendor}
dnl BEGIN configure.host.in
AC_PATH_PROG(CAT,cat)
AC_PATH_PROG(RM,rm)
AC_PATH_PROG(CP,cp)
AC_PATH_PROG(MV,mv)
AC_PATH_PROG(LN,ln)
AC_PROG_LN_S
AC_PATH_PROG(CHMOD,chmod)
AC_PATH_PROG(SORT,sort)
Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. Comments: * Added support for bsd "install" ($(BSDINSTALL)) to host.cfg.in, i.e. the standard "install" program that most packages (including automake) use. In Makefiles outside of rtems, "install" normally is referenced by $(INSTALL), but rtems already uses $(INSTALL) for install-if-change, hence I used $(BSDINSTALL) instead to keep up backward compatibility. * Removed references to @GREP@ etc. from host.cfg.in, as configure.in doesn't check for them (Minor cleanup). * Added installation flags INST*FLAGS to host.cfg.in, which should replace -m XXXX flags for installation calls. *Changes to gcc.cfg to enable it to build host programs from multiple sources files. Should not disturb existing sources, but neccessary. * There was a not-so-minor bug in the configuration files: "make install" and "make debug_install" don't work in all subdirectories!! I tried to fix this by adding "install" to MTARGETS in main.cfg, which seems to solve most of the problems. But there still seem to be rare (?) cases where "make debug_install" still seems to have problems. * Changes to many host related tool-Makefiles to demonstrate the abilities of INST*FLAGS, BSDINSTALL and the new rules in gcc.cfg. ..of cause ... but BSDINSTALL is THE standard method to install files in most program packages besides rtems. This part of the patch fixes some minor protection setting problems, but doesn't support TARGET_VARIANTS NOTE: I hope you will like the BSDINSTALL, INST*FLAGS stuff. It is a step to get rid of "install-if-change" and to rely on a more standard installation procedure. If you don't like BSDINSTALL, removing it from the patch isn't difficult- just grep for BSDINSTALL and replace BSDINSTALL with INSTALL or MKDIR. FINALLY: I still have another patch pending (well, not a complete patch yet, it's a partial patch to demonstrate the principle), which adds automatic rebuilding of files generated by autoconf/configure. At the moment I don't dare to submit it, because integrating this patch would require to modify all Makefile.ins because we'd need to add a new "include " line to each Makefile.in.
1998-07-17 15:49:12 +00:00
AC_PROG_INSTALL
RTEMS_PATH_PERL
dnl check mkdir behaviour, try to get mkdir -p -m 0755
RTEMS_PATH_MKDIR
RTEMS_PROG_MKDIR_M
RTEMS_PROG_MKDIR_P
test "$rtems_cv_prog_MKDIR_P" = "yes" && MKDIR="$MKDIR -p"
1998-08-20 15:46:07 +00:00
#test "$rtems_cv_prog_MKDIR_M" = "yes" && MKDIR="$MKDIR -m 0755"
AC_PATH_PROG(TOUCH,touch)
AC_PATH_PROG(CMP,cmp)
AC_PATH_PROG(SED,sed)
AC_PATH_PROGS(M4,gm4 m4)
RTEMS_PATH_KSH
dnl BEGIN configure.target.in
dnl echo "TARGET"
dnl echo " cpu --> $target_cpu"
dnl echo " os --> $target_os"
dnl echo " vendor --> $target_vendor"
dnl canonicalize target name
dnl NOTE: Most rtems targets do not fullfil autoconf
dnl targets naming conventions "processor-vendor-os"
dnl Therefore autoconf's AC_CANONICAL_TARGET will fail for them
dnl and we have to fix it for rtems ourselves
dnl
dnl The original plan was to do CPU-BSP-rtems or CPU-rtems to
dnl imply all BSPs. Eventually we would like to build a collection
dnl of CPU model specific RTEMS libraries which in conjunction with
dnl a BSP library would be used to link an application.
RTEMS_HOST=$host_os
RTEMS_CANONICAL_TARGET_CPU
changequote(,)dnl
case "${target}" in
# hpux unix port should go here
i[3456]86-go32-rtems*)
rtems_bsp="go32 go32_p5"
skip_startfiles="yes"
RTEMS_HAS_POSIX_API=no
;;
i[3456]86-pc-linux*) # unix "simulator" port
RTEMS_HOST=Linux
# override these settings
RTEMS_HAS_POSIX_API=no
;;
i[3456]86-*freebsd2*) # unix "simulator" port
RTEMS_HOST=FreeBSD
# override these settings
RTEMS_HAS_POSIX_API=no
;;
1998-02-11 21:20:43 +00:00
no_cpu-*rtems*)
RTEMS_HAS_POSIX_API=no
;;
sparc-sun-solaris*) # unix "simulator" port
RTEMS_HOST=Solaris
# override these settings
RTEMS_HAS_POSIX_API=no
;;
*)
;;
esac
changequote([,])dnl
# Override the set of BSPs to be built.
AC_ARG_ENABLE(rtemsbsp, \
[ --enable-rtemsbsp=bsp1 bsp2 .. BSPs to include in build], \
rtems_bsp=$enableval \
)
# Is this a supported CPU?
AC_MSG_CHECKING([if cpu $target_cpu is supported])
if test -d "$srcdir/c/src/exec/score/cpu/$target_cpu"; then
AC_MSG_RESULT(yes)
else
AC_MSG_ERROR(no)
fi
RTEMS_TOOL_PREFIX
dnl check target cc
RTEMS_PROG_CC
dnl check if the compiler supports --specs
RTEMS_GCC_SPECS
dnl check if the target compiler may use --pipe
RTEMS_GCC_PIPE
dnl check if the compiler supports --specs if gcc28 is requested
if test "$RTEMS_USE_GCC272" != "yes" ; then
if test "$rtems_cv_gcc_specs" = "no"; then
AC_MSG_WARN([*** disabling --enable-gcc28])
RTEMS_USE_GCC272=yes
fi
fi
test "$rtems_cv_gcc_pipe" = "yes" && CC_FOR_TARGET="$CC_FOR_TARGET --pipe"
dnl check for g++
if test "$RTEMS_HAS_CPLUSPLUS" = "yes"; then
RTEMS_PROG_CXX
if test "$rtems_cv_prog_cc_cross" != "$rtems_cv_prog_cxx_cross"; then
AC_MSG_ERROR([***]
[Inconsistency in compiler configuration:]
[Target C compiler and Target C++ compiler]
[must both either be cross compilers or native compilers]
[Hint: If building a posix bsp: LD_LIBRARY_PATH?] )
fi
else
CXX_FOR_TARGET="no"
fi
RTEMS_CANONICALIZE_TOOLS
dnl if this is an i386, does gas have good code16 support?
RTEMS_I386_GAS_CODE16
dnl check host cc
AC_PROG_CC
Monstrous patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. I have made no attempt to divide the comments up and place them with just the appropriate files. Here is an excerpt from Ralf's email: Changes including comments on changes I made after cycling through all the targets: * Added ranlib support. Now all targets use "ranlib" instead of "ar -s" to build an index for a library. If ranlib isn't detected during configuration, check if ar -s is working and try "ar -s" instead of * Removed $(XXX_FOR_TARGET) from make/target.cfg.in, use $(XXX) instead now. * gcc-target-default.cfg: LINK_XXXX-defines reworked to solve the -l problem under posix (cf gcc-target-default.cfg) * rtems-glom replaced by Makefile-rules inside of the wrapup/Makefile.in that has been using rtems-glom until now. * Removed CCC and friends in gcc-target-default.cfg, as they have been breaking CXX support. * Removed CONFIG.$(TARGET_ARCH).CC lines from several custom/*.cfg files, because this is now set in custom/default.cfg. * Added aclocal/ar-s.m4, check whether "ar -s" is working * Added aclocal/cygwin.m4 and aclocal/exeext.m4. * Reworked aclocal/canonicalize-tools.m4: Added ar -s check; fixes for problems when XXX_FOR_TARGET is given via environment variables (didn't work for gcc until now), adding cygwin check, improved autoconf-cache handling. * Removed -l from make rule dependencies. LINK_LIBS is now allowed to contain -L and -l. LINK_OBJS and LINK_FILES must not contain -L or -l. gcc28 make-exe rules now link using $(LINK_OBJS) $(LINK_LIBS) => Almost all custom/*.cfg are modified. This is very likely to break something because of typos or having missed to edit a file. Open problems, known bugs, things I didn't do: * custom/p4000.cfg seems to be out of date and requires to be reviewed. (JRS NOTE: It is subordinate p4650 and p4600 -- both of which build ok after minor changes.) * custom/psim.cfg needs to be reviewed, I added some changes to it, I am insecure about. (JRS NOTE: psim had a minor problem endif/endef swapped but runs fine.) * rtems-glom.in can now be removed. * gcc*.cfg files "make depend" rules don't honor language specific flags (e.g CXXFLAGS is ignored for *.cc) - Nothing to worry about now, but may cause problems for hosts/targets not using gcc or rtems-add-ons that use external packages. * AFAIS, the no_bsp BSP can't be build anymore, i.e. configure refused to configure for it whatever I tried. * The toplevel and toplevel+1 README files are quite out-dated * cygwin.m4 isn't of much use for rtems. In most cases (cf. aclocal/*.m4) it is worked around by directly using $host_os. I think I'll remove it soon after the next snapshot * Before release the cygwin patch needs to be tested under cygwin. I may have broken/missed something (esp. the sed-pattern to convert \\ into / may be broken). * You should try to build/run the posix-BSP under solaris - I don't expect problems, but I am not 100% sure, esp. with regard to ranlib/ar -s. * You should consider to convert all make/compilers/*.cfg files into make/compilers/*.cfg.in files and let autoconf generate the *.cfg. This may help getting rid of some if/then/else statements and help hard-coding some defines into those files in future and shouldn't disturb now. * Not having installed libc.a/libm.a on a host may still break building rtems, esp. when using -disable-gcc28 as the gcc27-configuration scheme directly accesses libc.a and libm.a. The problem should not appear when using gcc28 because it references libc/libm only through -lc and -lm which may be static or dynamic (I didn't test this). * shgen is not yet included (I didn't yet have enough time to integrate it). * I know about a few more configure-probs (esp. cross-checking --enable-* flags). + warn/refuse to configure when --enable-libcdir and --enable-gcc28 are given. + force --enable-libcdir when --disable-gcc28 is given * Replaced KSHELL with @KSH@ in some shell scripts generated by configure.in. * Added a dependency to aclocal/*.m4 in the toplevel Makefile => configure and aclocal.m4 will now be rebuild when any aclocal/*.m4 file is changed * Some changes to aclocal/gcc-pipe.m4 and aclocal/gcc-specs.m4 * Replaced i[[3456]]86-unknown-freebsd2.[[12]] with i[[3456]]86-*freebsd2.* in configure.in, as I suppose there might exist a variety of valid vendors (2nd field of the name-tripple) * Disabled override MAKEFLAGS in toplevel Makefile.in - Potential side-effects are not really clear to me. * In mvme162.cfg, $(LINK_LIBS) is missing in the CC line in gcc28's make-exe rule (yet another one I missed to edit). Just append $(LINK_LIBS) to the "CC" line, like I hopefully did to ALL other custom/*.cfg files. * the problem with mvme162lx.cfg is a follow-up problem of the mvme162.cfg-bug. * mvme162/console and idp/console had variables named Buffer which conflicted with similarly named variables in some tests.
1998-06-27 17:09:47 +00:00
RTEMS_CYGWIN32
RTEMS_EXEEXT
dnl FIXME: HACK for egcs/cygwin mixing '\\' and '/' in gcc -print-*
case $host_os in
*cygwin32*) GCCSED="| sed 's%\\\\%/%g'" ;;
*) ;;
esac
AC_SUBST(GCCSED)
dnl FIXME: This is a kludge
Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: 2. "make profile" doesn't work. It aborts when building host-tools for embedded targets. I didn't yet have enough time to fix this problem. AFAIS this problem is related to handling of LDFLAGS_PROFILE[|_V] in gcc.cfg.in. For host applications, we use gcc for linking host applications, too. With profiling enabled CFLAGS_PROFILE_V contains -pg and is used to compile, but LDFLAGS_PROFILE_V is empty, hence -pg will not be passed to the linker causing gcc to fail to link, because it can't resolve some symbols introduced by compiling with -pg. I am not sure if I can provide a patch for this - Ether it is trivial to fix or requires basic work on host configuration ;- Fixing this one was trivial - But hard to trace. LDFLAGS_PROFILE_V needs to contain the same flags as CFLAGS_PROFILE_V, if gcc is used for linking (What else should have been expected ?, :-). The same problem was present for *_DEBUG_V, but apparently wasn't noticed by anybody, because things didn't break, but were silently ignored. I fixed these problems by setting these flags in configure.in whenever gcc is reported to be the host-compiler. For non-gcc host compilers "make debug" and "make profile" now becomes the same as an ordinary "make". This is a hack and addressing this problen could be more sophisticated, but I don't think it gives much sense to support compile variants for any host program (Who will ever try to profile/debug host tools?). Therefore I don't think it's useful to invest more effort into this problem.
1998-10-14 19:42:45 +00:00
dnl Set flags to settings all gcc variants are assumed to accept.
if test "$ac_cv_prog_gcc" = "yes"; then
dnl Add -Wall if using gcc as host compiler
Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: 2. "make profile" doesn't work. It aborts when building host-tools for embedded targets. I didn't yet have enough time to fix this problem. AFAIS this problem is related to handling of LDFLAGS_PROFILE[|_V] in gcc.cfg.in. For host applications, we use gcc for linking host applications, too. With profiling enabled CFLAGS_PROFILE_V contains -pg and is used to compile, but LDFLAGS_PROFILE_V is empty, hence -pg will not be passed to the linker causing gcc to fail to link, because it can't resolve some symbols introduced by compiling with -pg. I am not sure if I can provide a patch for this - Ether it is trivial to fix or requires basic work on host configuration ;- Fixing this one was trivial - But hard to trace. LDFLAGS_PROFILE_V needs to contain the same flags as CFLAGS_PROFILE_V, if gcc is used for linking (What else should have been expected ?, :-). The same problem was present for *_DEBUG_V, but apparently wasn't noticed by anybody, because things didn't break, but were silently ignored. I fixed these problems by setting these flags in configure.in whenever gcc is reported to be the host-compiler. For non-gcc host compilers "make debug" and "make profile" now becomes the same as an ordinary "make". This is a hack and addressing this problen could be more sophisticated, but I don't think it gives much sense to support compile variants for any host program (Who will ever try to profile/debug host tools?). Therefore I don't think it's useful to invest more effort into this problem.
1998-10-14 19:42:45 +00:00
CC_CFLAGS_DEFAULT=-Wall
dnl Add -pg to profile flags, unless specified in the environment
CC_CFLAGS_PROFILE_V=${CC_CFLAGS_PROFILE_V-"-pg"}
dnl propagate cflags to ldflags, unless specified in the environment
CC_LDFLAGS_PROFILE_V=${CC_LDFLAGS_PROFILE_V-$CC_CFLAGS_PROFILE_V}
fi
dnl Add -g if the host compiler accepts -g, assume -g means debugging
Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: 2. "make profile" doesn't work. It aborts when building host-tools for embedded targets. I didn't yet have enough time to fix this problem. AFAIS this problem is related to handling of LDFLAGS_PROFILE[|_V] in gcc.cfg.in. For host applications, we use gcc for linking host applications, too. With profiling enabled CFLAGS_PROFILE_V contains -pg and is used to compile, but LDFLAGS_PROFILE_V is empty, hence -pg will not be passed to the linker causing gcc to fail to link, because it can't resolve some symbols introduced by compiling with -pg. I am not sure if I can provide a patch for this - Ether it is trivial to fix or requires basic work on host configuration ;- Fixing this one was trivial - But hard to trace. LDFLAGS_PROFILE_V needs to contain the same flags as CFLAGS_PROFILE_V, if gcc is used for linking (What else should have been expected ?, :-). The same problem was present for *_DEBUG_V, but apparently wasn't noticed by anybody, because things didn't break, but were silently ignored. I fixed these problems by setting these flags in configure.in whenever gcc is reported to be the host-compiler. For non-gcc host compilers "make debug" and "make profile" now becomes the same as an ordinary "make". This is a hack and addressing this problen could be more sophisticated, but I don't think it gives much sense to support compile variants for any host program (Who will ever try to profile/debug host tools?). Therefore I don't think it's useful to invest more effort into this problem.
1998-10-14 19:42:45 +00:00
test "$ac_cv_prog_cc_g" = "yes" && CC_CFLAGS_DEBUG_V=${CC_CFLAGS_DEBUG_V-"-g"}
dnl check for host library functions
dnl NOTE: must be called after AC_PROG_CC
AC_CHECK_FUNCS(strerror)
dnl check for SysV IPC used by simulators
if test "$target_cpu" = "unix" ; then
RTEMS_SYSV_SEM
if test "$rtems_cv_sysv_sem" != "yes" ; then
AC_MSG_ERROR([System V semaphores don't work, required by simulator])
fi
RTEMS_SYSV_SHM
if test "$rtems_cv_sysv_shm" != "yes" ; then
AC_MSG_ERROR([System V shared memory doesn't work, required by simulator])
fi
RTEMS_SYSV_MSG
if test "$rtems_cv_sysv_msg" != "yes" ; then
AC_MSG_ERROR([System V messages don't work, required by simulator])
fi
fi
# find all the Executive Makefiles
RTEMS_CHECK_MAKEFILE(c/src/exec/score/tools/$target_cpu)
RTEMS_CHECK_MAKEFILE(c/src/exec/rtems)
RTEMS_CHECK_MAKEFILE(c/src/exec/sapi)
RTEMS_CHECK_MAKEFILE(c/src/exec/score/cpu/$target_cpu)
if test "$RTEMS_HAS_POSIX_API" = "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/exec/posix)
makefiles="$makefiles c/src/exec/wrapup/posix/Makefile"
fi
# find all the Makefiles for the BSPs
if test -d "$srcdir/c/src/lib/libbsp/$target_cpu"; then
makefiles="$makefiles c/src/lib/libbsp/$target_cpu/Makefile"
if test -z "$rtems_bsp"; then
AC_MSG_CHECKING([for bsps])
files=`ls $srcdir/c/src/lib/libbsp/$target_cpu`
for file in $files; do
case $file in
shared*);;
Makefile*);;
READ*);;
CVS*);;
pxfl*);;
go32*);; # so the i386 port can pick up the other Makefiles
# Now account for BSPs with build variants
gen68360) rtems_bsp="$rtems_bsp gen68360 gen68360_040";;
p4000) rtems_bsp="$rtems_bsp p4600 p4650";;
mvme162) rtems_bsp="$rtems_bsp mvme162 mvme162lx";;
*) rtems_bsp="$rtems_bsp $file";;
esac;
done
makefiles="$makefiles c/src/lib/libbsp/bare/Makefile"
AC_MSG_RESULT([$rtems_bsp done])
fi
# collect makefiles for each bsp
for i in $rtems_bsp; do
# make sure there is a make/custom file for the bsp
if test ! -r "$srcdir/make/custom/${i}.cfg"; then
AC_MSG_ERROR([no make/custom/${i}.cfg file for BSP $i])
fi
# account for "aliased" bsps which share source code
case $i in
mvme162lx) bspdir=mvme162 ;; # mvme162 board variant
gen68360_040) bspdir=gen68360 ;; # 68360 in companion mode
go32_p5) bspdir=go32 ;; # go32 on Pentium class CPU
p4600) bspdir=p4000 ;; # p4000 board with IDT 4600
p4650) bspdir=p4000 ;; # p4000 board with IDT 4650
*) bspdir=$i;;
esac
# Is there code where there should be for this BSP?
# The bare bsp is a special case as it is not under the target_cpu path
case $i in
bare)
bspcpudir=
if test "X${BARE_CPU_CFLAGS}" = "X" ; then
AC_MSG_ERROR([--enable-bare-cpu-cflags not specified for bare bsp])
fi
if test "X${BARE_CPU_MODEL}" = "X" ; then
AC_MSG_ERROR([--enable-bare-cpu-model not specified for bare bsp])
fi
;;
*)
bspcpudir=$target_cpu/
;;
esac
if test -d "$srcdir/c/src/lib/libbsp/$bspcpudir$bspdir"; then
RTEMS_BSP_LIST="$RTEMS_BSP_LIST $i"
# make sure the Makefiles in a bsp directory are only done once
echo $bspdirs | grep $bspdir >/dev/null 2>&1
if test $? -ne 0 ; then
bspdirs="$bspdirs $bspdir"
RTEMS_CHECK_MAKEFILE(c/src/lib/libbsp/$bspcpudir$bspdir)
RTEMS_CHECK_MAKEFILE(c/src/lib/libbsp/${bspcpudir}shared)
fi
else
AC_MSG_ERROR([unable to find libbsp directory ($bspdir) for $i])
fi
done
fi
# find all the CPU dependent library Makefiles
RTEMS_CHECK_MAKEFILE(c/src/lib/libcpu/$target_cpu)
dnl Workaround for go32
if test "$skip_startfiles" != "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/lib/start/$target_cpu)
fi
dnl END configure.target.in
1998-01-22 22:46:55 +00:00
PROJECT_ROOT=`pwd;`
# If RTEMS macros are enabled, then use them. Otherwise, use inlines.
if test "$RTEMS_USE_MACROS" = "yes"; then
inline_dir=macros
if test "$RTEMS_HAS_POSIX_API" = "yes"; then
# The problem is that there is currently no code in posix/macros :)
AC_MSG_ERROR(Macros are not implemented for the POSIX API)
fi
else
inline_dir=inline
fi
# If the TCP/IP stack is enabled, then find all TCP/IP Makefiles
AC_MSG_CHECKING([if networking is enabled? ])
AC_MSG_RESULT($RTEMS_HAS_NETWORKING)
if test "$RTEMS_HAS_NETWORKING" = "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/lib/libnetworking)
RTEMS_CHECK_MAKEFILE(c/src/lib/librpc)
if test "$RTEMS_HAS_RDBG" = "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/lib/librdbg)
fi
fi
# If the C++ support is enabled, then include the Makefiles
if test "$RTEMS_HAS_CPLUSPLUS" = "yes"; then
makefiles="$makefiles c/src/lib/librtems++/Makefile"
fi
1997-05-27 23:39:29 +00:00
# If the tests are enabled, then find all the test suite Makefiles
AC_MSG_CHECKING([if the test suites are enabled? ])
tests_enabled=no
AC_ARG_ENABLE(tests, \
[ --enable-tests enable tests (default:disabled)], \
[case "${enableval}" in
yes) AC_MSG_RESULT(yes) ; tests_enabled=yes ;;
no) AC_MSG_RESULT(no) ; tests_enabled=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for tests option) ;;
esac],
AC_MSG_RESULT(no)
)
RTEMS_CHECK_MAKEFILE(c/src/tests/tools/$target_cpu)
if test "$tests_enabled" = "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/tests/libtests)
RTEMS_CHECK_MAKEFILE(c/src/tests/sptests)
RTEMS_CHECK_MAKEFILE(c/src/tests/tmtests)
if test "$RTEMS_HAS_MULTIPROCESSING" = "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/tests/mptests)
fi
if test "$RTEMS_HAS_POSIX_API" = "yes"; then
RTEMS_CHECK_MAKEFILE(c/src/tests/psxtests)
fi
fi
# If the HWAPI is enabled, the find the HWAPI Makefiles
AC_MSG_CHECKING([if the HWAPI is enabled? ])
AC_ARG_ENABLE(hwapi, \
[ --enable-hwapi enable hardware API library], \
[case "${enableval}" in
yes) AC_MSG_RESULT(yes)
if test -f ${srcdir}/c/src/lib/libhwapi/Makefile.in ; then
makefiles="$makefiles c/src/lib/libhwapi/Makefile"
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/analog)
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/discrete)
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/drivers)
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/non_volatile_memory)
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/serial)
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/support)
RTEMS_CHECK_MAKEFILE(c/src/lib/libhwapi/wrapup)
else
AC_MSG_ERROR(No source code found for the HWAPI)
fi
;;
no) AC_MSG_RESULT(no) ;;
*) AC_MSG_ERROR(bad value ${enableval} for hwapi option) ;;
esac],
AC_MSG_RESULT(no)
)
AC_SUBST(RTEMS_GAS_CODE16)
AC_SUBST(rtems_cv_prog_cc_cross)
1997-12-16 18:40:08 +00:00
AC_SUBST(RTEMS_BSP_LIST)
AC_SUBST(RTEMS_HOST)
AC_SUBST(RTEMS_LIBC_DIR)
AC_SUBST(RTEMS_USE_OWN_PDIR)
AC_SUBST(RTEMS_HAS_POSIX_API)
AC_SUBST(RTEMS_HAS_NETWORKING)
AC_SUBST(RTEMS_HAS_RDBG)
AC_SUBST(RTEMS_USE_MACROS)
AC_SUBST(RTEMS_HAS_CPLUSPLUS)
AC_SUBST(RTEMS_USE_GCC272)
AC_SUBST(RTEMS_LIBC_DIR)
AC_SUBST(BARE_CPU_CFLAGS)
AC_SUBST(BARE_CPU_MODEL)
AC_SUBST(PROJECT_ROOT)
AC_SUBST(program_prefix)
AC_SUBST(CC_CFLAGS_DEFAULT)
AC_SUBST(CC_CFLAGS_DEBUG_V)
Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: 2. "make profile" doesn't work. It aborts when building host-tools for embedded targets. I didn't yet have enough time to fix this problem. AFAIS this problem is related to handling of LDFLAGS_PROFILE[|_V] in gcc.cfg.in. For host applications, we use gcc for linking host applications, too. With profiling enabled CFLAGS_PROFILE_V contains -pg and is used to compile, but LDFLAGS_PROFILE_V is empty, hence -pg will not be passed to the linker causing gcc to fail to link, because it can't resolve some symbols introduced by compiling with -pg. I am not sure if I can provide a patch for this - Ether it is trivial to fix or requires basic work on host configuration ;- Fixing this one was trivial - But hard to trace. LDFLAGS_PROFILE_V needs to contain the same flags as CFLAGS_PROFILE_V, if gcc is used for linking (What else should have been expected ?, :-). The same problem was present for *_DEBUG_V, but apparently wasn't noticed by anybody, because things didn't break, but were silently ignored. I fixed these problems by setting these flags in configure.in whenever gcc is reported to be the host-compiler. For non-gcc host compilers "make debug" and "make profile" now becomes the same as an ordinary "make". This is a hack and addressing this problen could be more sophisticated, but I don't think it gives much sense to support compile variants for any host program (Who will ever try to profile/debug host tools?). Therefore I don't think it's useful to invest more effort into this problem.
1998-10-14 19:42:45 +00:00
AC_SUBST(CC_CFLAGS_PROFILE_V)
AC_SUBST(CC_LDFLAGS_PROFILE_V)
# pick up all the Makefiles in required parts of the tree
RTEMS_CHECK_MAKEFILE(c/build-tools)
RTEMS_CHECK_MAKEFILE(make)
RTEMS_CHECK_MAKEFILE(c/src/lib/libchip)
RTEMS_CHECK_MAKEFILE(c/src/lib/libmisc)
RTEMS_CHECK_MAKEFILE(c/src/tests/samples)
1998-01-30 20:57:53 +00:00
AC_CONFIG_HEADER(c/build-tools/src/config.h)
# try not to explicitly list a Makefile here
AC_OUTPUT(
Makefile
make/host.cfg
make/target.cfg
make/Templates/Makefile.inc
make/compilers/gcc.cfg
c/Makefile
c/src/Makefile
c/src/exec/Makefile
c/src/exec/score/Makefile
c/src/exec/score/cpu/Makefile
c/src/exec/score/include/Makefile
c/src/exec/score/include/rtems/Makefile
c/src/exec/score/include/rtems/wrap/Makefile
c/src/exec/score/include/rtems/score/Makefile
c/src/exec/score/${inline_dir}/Makefile
c/src/exec/score/${inline_dir}/rtems/Makefile
c/src/exec/score/${inline_dir}/rtems/score/Makefile
c/src/exec/score/src/Makefile
c/src/exec/score/tools/Makefile
c/src/exec/score/tools/generic/Makefile
c/src/exec/wrapup/Makefile
c/src/exec/wrapup/rtems/Makefile
c/src/lib/Makefile
c/src/lib/include/Makefile
c/src/lib/libbsp/Makefile
c/src/lib/libbsp/shmdr/Makefile
c/src/lib/libc/Makefile
c/src/lib/libcpu/Makefile
c/src/lib/start/Makefile
c/src/lib/wrapup/Makefile
c/src/tests/Makefile
c/src/tests/support/Makefile
c/src/tests/support/include/Makefile
c/src/tests/support/stubdr/Makefile
c/src/tests/support/wrapup/Makefile
c/src/tests/tools/Makefile
c/src/tests/tools/generic/Makefile
$makefiles
c/update-tools/Makefile)
echo
echo target architecture: $target_cpu.
echo available BSPs: $rtems_bsp.
1997-12-16 18:40:08 +00:00
echo \'make all\' will build the following BSPs: $RTEMS_BSP_LIST.
echo other BSPs can be built with \'make RTEMS_BSP=\"bsp1 bsp2 ...\"\'
echo