summaryrefslogtreecommitdiffstats
path: root/tools/build/scripts/rcs-clean.in (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de> to reorganizeJoel Sherrill1999-04-191-73/+0
| | | | | | | | | | | the build-tools layout to simplify it. This script reorganizes and simpilfies the build-tools subdirectories. It moves all source-files and scripts to c/build-tools/. This will enable use to use this directory directly to refer to the build-tools instead of copying them around in a "preinstall" step in future. However, RTEMS's autoconf Makefile.ins and *.cfg files are not yet prepared to apply this approach and therefore require additional work.
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1998-10-141-0/+73
1. Rtems contains some perl scripts that use hard-coded paths to /usr/bin/perl or /usr/local/bin/perl I have already fixed these problems by adding some checks to configure.in. While doing this, I also cleaned up some more autoconf related problems for generating shell scripts. This patch might seem a bit scary to you, but I am quite confident it won't break something (I've been testing it for almost a week now, however it might introduce typos for a limited number configurations I don't have access to - But it shouldn't be a problem for you to test them :-). I expect to get this finished tonight, hence you will very likely have the patch when you get up tomorrow. Changes: * Check for PERL and disable all PERL scripts if perl wasn't found. * Generate all KSHELL-scripts with autoconf instead of make-script * Automatic dependency handling for autoconf generated KSHELL or PERL scripts (make/rtems.cfg) Notes: * this patch contains new files and deletes some other files. * The patch is relative to rtems-4.0.0-beta4 with my previous rtems-rc-981014-1.diff patch applied. Testing: I tested it with sh-rtems and posix under linux. Now all targets which are touched by this patch and which are not used while building for sh-rtems and posix still need to be tested. AFAIS, only the sparc/erc32 BSP should be affected by this criterion. And if you like to, you should also consider testing it on a Cygwin32 and a Solaris host for one arbitrary BSP.