Files
rtems/bootstrap

327 lines
8.5 KiB
Plaintext
Raw Normal View History

2012-07-27 15:38:04 +02:00
#!/bin/sh
#
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
# helps bootstrapping, when checked out from CVS
# requires GNU autoconf and GNU automake
#
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
# this is not meant to be exported outside the source tree
#
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
# NOTE: Inspired by libtool's autogen script
#
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
# to be run from the toplevel directory of RTEMS'
# source tree
progname=`basename $0`
2000-06-12 15:00:15 +00:00
top_srcdir=`dirname $0`
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
LC_ALL=C
export LC_ALL
2012-07-27 15:38:04 +02:00
verbose=""
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
quiet="false"
mode="autoreconf"
force=0
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
usage()
{
echo
echo "usage: ${progname} [-c|-h|-H] [-q][-v]"
echo
echo "options:"
echo " -c .. clean, remove all aclocal/autoconf/automake generated files"
echo " -h .. display this message and exit"
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
echo " -H .. regenerate headers.am files"
echo " -q .. quiet, don't display directories"
echo " -v .. verbose, pass -v to autotools"
echo
2012-07-27 15:38:04 +02:00
exit 1
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
}
if test ! -f $top_srcdir/aclocal/version.m4; then
echo "${progname}:"
echo " Installation problem: Can't find file aclocal/version.m4"
2012-07-27 15:38:04 +02:00
exit 1
fi
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
while test $# -gt 0; do
case $1 in
-h|--he|--hel|--help)
usage ;;
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
-q|--qu|--qui|--quie|--quiet)
2012-07-27 15:38:04 +02:00
quiet="true"
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
shift;;
-v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
2012-07-27 15:38:04 +02:00
verbose="-v"
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
shift;;
-c|--cl|--cle|--clea|--clean)
2012-07-27 15:38:04 +02:00
mode="clean"
shift;;
-f|--fo|--for|--forc|--force)
force=`expr $force + 1`
shift;;
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
-H|--headers)
mode="headers"
shift;;
2006-11-18 06:07:06 +00:00
-r|--re|--rec|--reco|--recon|--reconf)
2012-07-27 15:38:04 +02:00
mode="autoreconf"
2006-11-18 06:07:06 +00:00
shift;;
-g|--ge|--gen|--gene|--gener|--genera|--generat|--generate)
2012-07-27 15:38:04 +02:00
mode="generate"
shift;;
2012-07-27 15:38:04 +02:00
-*) echo "unknown option $1"
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
usage ;;
2012-07-27 15:38:04 +02:00
*) echo "invalid parameter $1"
Towards automake IX patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>: This is the next step towards automake: * Two scripts for the toplevel directory: a) "autogen" (Idea borrowed from libtool and gnome) A helper script to recursively regenerate autoconf/automake/aclocal generated files (Still not perfect but sufficient). b) "missing" (from automake-cvs archive). This file normally is automatically generated by automake, but we have to manually add it until we add automake support to the toplevel configure script. "chmod 755 missing autogen" after applying the patch. * Changing the toplevel installation directory [ I can hear you falling off the chair ;-] Until now rtems installed itself to $(prefix)/rtems. This is in contradiction to automake and GNU/FSF/Cygnus conventions. With this patch applied, rtems installs into $(prefix). To achieve the old behaviour simply configure with --prefix=<install-dir>/rtems instead of --prefix=<install-dir> This is a widely visible change and I can understand if you don't like it at the present point. It enables us to use automake's default installation paths instead of having to set up installation paths manually. At the moment this doesn't help much, but in the not so far future this would enable us to mix cpu-only dependent libraries into the host's cross-compiler library and header files into newlib's include directories, tools into the toolchain directories etc. I would recommend to change the main installation directory, however it's up to you to draw the final design decision.
1999-03-19 22:01:26 +00:00
usage ;;
esac
done
case $mode in
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
headers)
if test "." != "$top_srcdir"; then
echo "To generate the headers.am you must call the script via \"./$progname -H\""
exit 1
fi
base="$PWD"
# Generate cpukit/header-dirs.am
tmp="$base/cpukit/header-dirs.am.new"
hdr_dirs=`for i in cpukit/include cpukit/libnetworking cpukit/score/cpu/*/include ; do
cd "$i"
find -mindepth 1 -type d
cd "$base"
done | sort -u | sed 's%^\./%%'`
echo '## This file was generated by "./boostrap -H".' > "$tmp"
echo 'include_HEADERS =' >> "$tmp"
for dir in $hdr_dirs ; do
am_dir=`echo $dir | sed 's%[/-]%_%g'`
echo "include_${am_dir}dir = \$(includedir)/$dir" >> "$tmp"
echo "include_${am_dir}_HEADERS =" >> "$tmp"
done
diff -q "$tmp" "cpukit/header-dirs.am" || mv "$tmp" "cpukit/header-dirs.am"
rm -f "$tmp"
# Generate cpukit/*/headers.am
tmp="$base/headers.am.new"
cpukit="$base/cpukit"
cd "$cpukit"
for inc in include score/cpu/*/include ; do
echo '## This file was generated by "./boostrap -H".' > "$tmp"
hdr=`dirname $inc`
am_dir=""
cd $inc
for b in `find -type d | sort` ; do
for j in `find $b -mindepth 1 -maxdepth 1 -name '*.h' | sed 's%^\.%%' | sed 's%^/%%' | sort` ; do
dir=`dirname $j`
if test x$dir != x. ; then
am_dir=`echo $dir | sed 's%[/-]%_%g'`
am_dir="_$am_dir"
else
am_dir=""
fi
echo "include${am_dir}_HEADERS += $inc/$j" >> "$tmp"
done
done
cd "$cpukit"
diff -q "$tmp" "${hdr}/headers.am" || mv "$tmp" "${hdr}/headers.am"
done
rm -f "$tmp"
cd "$base"
# Generate bsps/*/headers.am
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
tmp="$base/headers.am.new"
for i in bsps/include bsps/*/include bsps/*/*/include ; do
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
dir=""
am_dir=""
echo '## This file was generated by "./boostrap -H".' > "$tmp"
case $i in
bsps/*/*/include)
hdr="../"
inc="../../../../../../$i/"
;;
bsps/*/include)
hdr="../"
inc="../../../../../$i/"
;;
bsps/include)
hdr="../"
inc="../../$i/"
;;
*)
hdr=""
inc=""
;;
esac
cd $i
for b in `find -type d | sort` ; do
for j in `find $b -mindepth 1 -maxdepth 1 -name '*.h' -or -name '*.inc' | sed 's%^\.%%' | sed 's%^/%%' | sort` ; do
d=`dirname $j`
if test x$d != x$dir ; then
dir=$d
if test x$d != x. ; then
am_dir=`echo $dir | sed 's%[/-]%_%g'`
am_dir="_$am_dir"
printf "\ninclude%sdir = \$(includedir)/$dir\n" "$am_dir" >> "$tmp"
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
else
am_dir=""
echo "" >> "$tmp"
fi
echo "include${am_dir}_HEADERS =" >> "$tmp"
fi
echo "include${am_dir}_HEADERS += $inc$j" >> "$tmp"
if test $j = bsp.h ; then
echo "include_HEADERS += include/bspopts.h" >> "$tmp"
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
fi
done
done
cd "$base"
diff -q "$tmp" "$i/${hdr}headers.am" || mv "$tmp" "$i/${hdr}headers.am"
done
Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: * The make preinstall step itself needs time and disk space. * Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. * There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. * The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. * An introduction of a new build system is difficult. * Include paths specified by the -B option are system headers. This may suppress warnings. * The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: * cpukit/include * cpukit/score/cpu/@RTEMS_CPU@/include * cpukit/libnetworking The new BSP include directories are: * bsps/include * bsps/@RTEMS_CPU@/include * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
2017-12-23 18:18:56 +11:00
rm -f "$tmp"
;;
generate)
AUTOCONF=${AUTOCONF-autoconf}
if test -z "$AUTOCONF"; then
echo "You must have autoconf installed to run $program"
2003-03-25 08:50:16 +00:00
exit 1
fi
2012-07-27 15:38:04 +02:00
2003-03-25 08:50:16 +00:00
AUTOHEADER=${AUTOHEADER-autoheader}
if test -z "$AUTOHEADER"; then
echo "You must have autoconf installed to run $program"
exit 1
fi
2012-07-27 15:38:04 +02:00
AUTOMAKE=${AUTOMAKE-automake}
if test -z "$AUTOMAKE"; then
echo "You must have automake installed to run $program"
2003-03-25 08:50:16 +00:00
exit 1
fi
2012-07-27 15:38:04 +02:00
2003-03-25 08:50:16 +00:00
ACLOCAL=${ACLOCAL-aclocal}
if test -z "$ACLOCAL"; then
echo "You must have automake installed to run $program"
exit 1
fi
2000-06-12 15:00:15 +00:00
case $top_srcdir in
/* ) aclocal_dir=$top_srcdir
2000-06-12 15:00:15 +00:00
;;
*) aclocal_dir=`pwd`/$top_srcdir
2000-06-12 15:00:15 +00:00
;;
esac
confs=`find . \( -name 'configure.in' -o -name 'configure.ac' \) -print`
for i in $confs; do
2012-07-27 15:38:04 +02:00
dir=`dirname $i`
configure=`basename $i`
( test "$quiet" = "true" || echo "$dir"
cd $dir
pat="s,\$(RTEMS_TOPdir),${aclocal_dir},g"
aclocal_args=`grep '^[ ]*ACLOCAL_AMFLAGS' Makefile.am | \
2012-07-27 15:38:04 +02:00
sed -e 's%.*ACLOCAL_AMFLAGS.*\=[ ]*%%g' -e $pat `
2003-03-25 08:50:16 +00:00
test "$verbose" = "-v" && echo "${ACLOCAL} $aclocal_args"
2012-07-27 15:38:04 +02:00
${ACLOCAL} $aclocal_args
2003-03-25 08:50:16 +00:00
test -n "`grep CONFIG_HEADER ${configure}`" && ${AUTOHEADER} \
2012-07-27 15:38:04 +02:00
&& test "$verbose" = "-v" && echo "${AUTOHEADER}"
2003-03-25 08:50:16 +00:00
test -n "`grep RTEMS_BSP_CONFIGURE ${configure}`" && ${AUTOHEADER} \
2012-07-27 15:38:04 +02:00
&& test "$verbose" = "-v" && echo "${AUTOHEADER}"
test -f Makefile.am && ${AUTOMAKE} -a -c $verbose
${AUTOCONF}
test -f Makefile.am && test -n "`grep 'stamp-h\.in' Makefile.in`" \
&& echo timestamp > stamp-h.in
)
done
;;
2000-06-12 15:00:15 +00:00
2006-11-18 06:07:06 +00:00
autoreconf)
AUTORECONF=${AUTORECONF-autoreconf}
if test -z "$AUTORECONF"; then
echo "You must have autoreconf installed to run $program"
exit 1
fi
confs=`find . -name 'configure.ac' -print`
for i in $confs; do
2012-07-27 15:38:04 +02:00
dir=`dirname $i`
configure=`basename $i`
( test "$quiet" = "true" || echo "$dir"
cd $dir
${AUTORECONF} -i --no-recursive $verbose
2006-11-18 06:07:06 +00:00
test -f Makefile.am && test -n "`grep 'stamp-h\.in' Makefile.in`" \
&& echo timestamp > stamp-h.in
)
done
;;
clean)
test "$quiet" = "true" || echo "removing automake generated Makefile.in files"
2012-07-27 15:38:04 +02:00
files=`find . -name 'Makefile.am' -print | sed -e 's%\.am%\.in%g'`
for i in $files; do
if test -f $i; then
rm -f $i
2012-07-27 15:38:04 +02:00
test "$verbose" = "-v" && echo "$i"
fi
done
test "$quiet" = "true" || echo "removing configure files"
2012-07-27 15:38:04 +02:00
files=`find . -name 'configure' -print`
for i in $files; do
if test -f $i; then
rm -f $i
test "$verbose" = "-v" && echo "$i"
2012-07-27 15:38:04 +02:00
fi
done
2012-07-27 15:38:04 +02:00
if test $force -gt 0; then
needles=""
if test $force -gt 1; then
# Manually maintained
needles="$needles config.sub"
needles="$needles config.guess"
fi
if test $force -gt 0; then
# Inherited from automake
needles="$needles compile"
needles="$needles depcomp"
needles="$needles install-sh"
needles="$needles missing"
needles="$needles mdate-sh"
fi
for j in $needles; do
files=`find . -name "$j" -print`
2012-07-27 15:38:04 +02:00
for i in $files; do
if test -f $i; then
rm -f $i
test "$verbose" = "-v" && echo "$i"
2012-07-27 15:38:04 +02:00
fi
done
done
fi
test "$quiet" = "true" || echo "removing aclocal.m4 files"
2012-07-27 15:38:04 +02:00
files=`find . -name 'aclocal.m4' -print`
test "$verbose" = "-v" && test -n "$files" && echo "$files"
for i in $files; do
if test -f $i; then
rm -f $i
2012-07-27 15:38:04 +02:00
test "$verbose" = "-v" && echo "$i"
fi
done
find . -name '*~' -print | xargs rm -f
find . -name 'bspopts.h.in' -print | xargs rm -f
find . -name '*.orig' -print | xargs rm -f
find . -name '*.rej' -print | xargs rm -f
find . -name 'config.status' -print | xargs rm -f
find . -name 'config.log' -print | xargs rm -f
find . -name 'config.cache' -print | xargs rm -f
find . -name 'Makefile' -and -not -path ./testsuites/ada/sptests/sp19/Makefile -print | xargs rm -f
find . -name '.deps' -print | xargs rm -rf
find . -name '.libs' -print | xargs rm -rf
find . -name 'stamp-h.in' | xargs rm -rf
find . -name 'autom4te*.cache' | xargs rm -rf
;;
esac
exit 0