| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
old_priority parameter is provided.
|
|
|
|
| |
in various BSPs.
|
| |
|
|
|
|
| |
BSP as we transition to more .o's and less .rel's.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
reduce the size of executables.
|
|
|
|
|
|
| |
Here's a tiny patch that shreds memory returned to the pool (such as by
free() and delete). This may help people find some nasty
bugs, so here it is.
|
|
|
|
| |
wrapped by calls to _Thread_Enable_dispatch and _Thread_Disable_dispatch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is an enhancement to acpolish.
It replaces some Makefile variables by others variable in Makefile.ins
(tries to use unique name for some variables). It therefore eases
parsing Makefile.ins for further automatic Makefile.in conversions in
future.
To apply:
cd <rtems-source-tree>
sh <path-to>/rtems-rc-19990407-8.sh
./autogen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, the unlimited patch. I have compiled the unlmited patch for the
Linux posix BSP only and it seems to work cleanly. I would like a really
major application run on this change before commiting as the changes are
very core and significant. I am currently building all the tests to run.
I have no targets suitable to test on at the moment.
I have tested the patch for inline functions and macros.
Turning macros on has found some core bugs. I have fixed these but have
not run all the tests. Please review the patch for these changes. They
are:
1) The conditional compilation for MP support broke the core messages
code. You cannot embed a conditional macro in another macro. The Send
and Urgent Send calls are macros.
2) User extensions handler initialisation now has two parameters. I have
updated the macros to support the extra parameter.
The patch also contains the gcc-target-default.cfg fix required to build
the kernel. More of a by product than a fix for you.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
it work.
|
|
|
|
| |
when building the executive source.
|
|
|
|
| |
via the user api.
|
|
|
|
|
|
|
|
|
|
|
| |
task to be deleted was created via the same API (i.e. were of the object
class created by this API). For example, a POSIX thread calling
the rtems_task_delete(SELF) directive would incorrectly update the RTEMS
object local pointer table.
Jennifer discovered this when moving tests implemented in C using the
Classic RTEMS API into a tree of Ada tests. The Ada tests were implicitly
using POSIX services. This lead to some unexpected behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
|
|
| |
to lib/include.
Went to using a PROJECT_INCLUDE variable.
|
| |
|
| |
|
|
|
|
|
| |
but which did not have real bodies. This is necessary for languages
like Ada95 which must have real entries in a library for bindings.
|
| |
|
| |
|