| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 5) rtems-rc-19990202-1.diff/reorg-install.sh
>
> reorg-install.sh fixes a Makefile variable name clash of RTEMS
> configuration files and automake/autoconf standards.
> Until now, RTEMS used $(INSTALL) for install-if-change. Automake and
> autoconf use $(INSTALL) for a bsd-compatible install. As
> install-if-change and bsd-install are not compatible, I renamed all
> references to install-if-changed to $(INSTALL_CHANGED) and used
> $(INSTALL) for bsd-install (==automake/autoconf standard). When
> automake will be introduced install-if-change will probably be replaced
> by $(INSTALL) and therefore will slowly vanish. For the moment, this
> patch fixes a very nasty problem which prevents adding any automake file
> until now (There are still more).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make solaris target buildable.
> 1. The ipc check fails since solaris does not define union semun.
> The unix port code actually defines this type itself on solaris. Doing
> the same thing lets it get configured. Then...
> 2. It looks like BSDINSTALL is not defined properly.
BSDINSTALL is defined in make/host.cfg.in as
BSDINSTALL=@INSTALL@
@INSTALL@ is generated by autoconf's standard macro AC_PROG_INSTALL, which
is widely used in almost any autoconf/automake configured package. In case
there is really something wrong with it, then it must be considered a bug
in autoconf.
I can see a doubious fragment in AC_PROG_INSTALL, which is used when no
appropriate bsd-install is found.
Finally Ralf saw a problem with the find on solaris which I also saw and
fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working
with different shells and relative/absolute paths.
What I did is relatively simple in principle:
Instead of setting RTEMS_ROOT in configure.in and then let configure
substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile
set RTEMS_ROOT from each Makefile's @top_srcdir@ value.
The difference is subtile, but with enormous side effects:
- If RTEMS_ROOT is set in configure, then the same single value will be
propagated to all Makefiles. This breaks using relative paths, as the
relative path to the root of the source tree is used inside of all
subdirectory Makefiles.
- Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is
computed individually by configure for each single Makefile.in, hereby
receiving the correct value, no matter if relative or absolute paths are
used.
To get this working, I needed to remove setting RTEMS_ROOT from
target.cfg.in, because this overrides the value of RTEMS_ROOT from each
individual Makefile.
Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all
"include $(RTEMS_CUSTOM)" directives with"include
$(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this,
but I think, to have one variable less is clearer and easier to
understand than having several variables refering to the next one.
I enclose a small patch to this mail, which
- fixes the config.h problem (to finally clearify misunderstands)
- removes assignment/subsitution of RTEMS_ROOT from configure.in
- contains a workaround for the application Makefile's RTEMS_ROOT
problem (reported by Eric)
- removes some unused lines from the toplevel Makefile.in
- removes assignment of RTEMS_ROOT from make/target.cfg.in
|
| | |
|
| |
|
|
|
| |
any directory in the build tree. The only variable which must be set
before the command "gmake" is invoked is RTEMS_BSP (e.g. RTEMS_BSP=erc32).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU autoconf. This is the first large step in allowing an RTEMS
user to perform a one-tree build (per crossgcc FAQ) including RTEMS
in the build process. With this change RTEMS is configured in
built in the same style as the GNU tools, yet retains the basic
structure of its traditional Makefiles (ala Tony Bennett).
Jiri Gaisler (jgais@wd.estec.esa.nl) deserves (and received)
a big thank you for doing this.
There are still issues to be resolved but as of this commit, all target
which can be built on a linux host have been using a modified version
of the source Jiri submitted. This source was merged and most targets
built in the tree before this commit.
There are some issues which remain to be resolved but they are primarily
related to host OS dependencies, script issues, the use of gawk
for hack_specs, and the dependence on gcc snapshots. These will
be resolved.
|
| | |
|
| | |
|
| | |
|
| |
|
