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
for GNAT. It was the number of Ada tasks when in fact the run-time
only required a single key.
Also added the CONFIGURE_MAXIMUM_FAKE_ADA_TASKS constant to account
for resources allocated for each non-Ada task/thread which invokes
the Ada run-time implicitly through an Ada call.
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.
the inline implementation. The impetus for this was twofold. First,
it is incorrect to have static inline prototypes when using the macro
implementation. Second, this reduced the number of lines in the include
files seen by rtems.h by about 2000 lines.
Next we restricted visibility for the inline routines to inside the
executive itself EXCEPT for a handful of objects. This reduced the
number of include files included by rtems.h by 40 files and reduced
the lines in the include files seen by rtems.h by about 6000 lines.
In total, these reduced the compile time of the entire RTEMS tree by 20%.
This results in about 8 minutes savings on the SparcStation 10 morgana.
the thread handler (IDLE), MPCI object (SYSI now MP Receive)
and initialize_executive_early (IO initialization). The SYSI task
no longer exists in a single processor configuration. This reduces
single processor Workspace requirements by a TCB and a stack which
is often larger than the minimum stack size. Moving the IO initialization
plus accompanying BSP hooks eliminated an initialization ordering problem
in which a global task could be created before the MPCI was initialized.
