| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> When I run my script that just repeatedly builds different targets, some
> of them die with an error like this:
>
> Making all RTEMS_BSP=gen68360 in cpugmake[5]: Entering directory
> `/usr1/rtems/build/build-m68k-rtems/c/src/exec/score/cpu'
> Making all RTEMS_BSP=gen68360 in @RTEMS_CPU@
> /bin/sh: @RTEMS_CPU@: No such file or directory
> gmake[5]: *** [all] Error 1
> gmake[5]: Leaving directory
> `/usr1/rtems/build/build-m68k-rtems/c/src/exec/score/cpu'
>
> It is not always the same variable substitution that fails. Sometimes it
> is @INSTALL@. But reliably, it is a variable substitution that is
> failing.
>
> Do you have any idea why this happens?
Yep, I think I know what's going on.
AC_SUBST(RTEMS_CPU) is missing in configure.ins, thus @RTEMS_CPU@ in
target.cfg.in doesn't get substituted correctly, causing the bug above. Due
to the redundancy of RTEMS_CPU, other most BSPs don't seem to be affected.
Other similar problems probably exist for the unix/posix bsp and the hppa.1
cpu, because their */tools/*Makefile.ams require RTEMS_CPU, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch should fix the nastiest configuration bugs for no_cpu/no_bsp.
With this patch applied, configure --target=no_cpu-rtems now correctly
acknowledges its configuration, but later fails building when trying to
build libcsupport (I leave this problem for you :-).
Fixes/Changes:
* aclocal/canonicalize-target-name.m4: use RTEMS_CPU instead of
target_cpu, switch to a native compiler setup if target = no_cpu*rtems,
ie. implicitly use host=target (native) and RTEMS_CPU=no_cpu for
--target=no_cpu*rtems.
* add no_bsp/bsp_specs (Support -qrtems, -qrtems_debug; please check
before adding :-)
* Use RTEMS_CANONICALIZE_TARGET_CPU instead of AC_CANONICAL_SYSTEM in
toplevel/configure.in
* All references to $target_cpu in aclocal/*.m4, Makefile.ins and *.cfg
files changed to RTEMS_CPU
* bug fixes to exec/score/cpu/no_cpu/wrap (This part of the patch may
result into patch rejections, because your recently posted patch may
also have addressed this problem).
After applying this patch, please do:
cvs add c/src/lib/libbsp/no_cpu/no_bsp/bsp_specs
./autogen
|
| |
|
|
|
| |
BSP (BSP_PIECES) to picking up the .o files. This should help
reduce the minimum size of an application.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 addresses a few minor issues and contains a few (minor)
preparations for automake.
* configure.in: Fix for handing c/src/tests subdirectory handling (FIX)
* aclocal/rtems-top.m4:
+ Add TARGET_SUBDIR and --with-target-subdir (preparation of future
enhancements for cross-compiling)
+ Activate RTEMS_ROOT handling (automake preparation)
* automake/*.am: replace comments "#" with "##" so that comments won't
get included into Makefile.in's anymore
* c/update-tools/* automake support (NEW)
* ./autogen update/enhancement (cf. ./autogen for details)
After applying this patch please run:
./autogen
cvs add c/update-tools/configure.in
cvs add c/update-tools/Makefile.am
cvs add c/update-tools/aclocal.m4
|
| |
|
|
| |
all bsp_specs.
|
| |
|
|
| |
Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
description follows:
Description:
* automake for *all* tool subdirectories (Makefile.am, configure.in etc.)
* autogen now also considers CONFIG_HEADER (generates stamp-h.ins and
config.h.ins)
* c/src/tests/tools/generic/difftest and
c/src/tests/tools/generic/sorttimes generated by configure scripts
* c/update-tools/ampolish, beautifier for Makefile.ams, similar to
acpolish
* rtems-polish.sh added to c/update-tools/ + ampolish support
* New subdirectory ./automake, contains automake -Makefile fragments to
support RTEMS make "debug, debug_install, profile, profile_install" for
native Makefile.ams (== ignore these make targets).
* aclocal/rtems-top.m4's RTEMS_TOP now reads the automake makefile
variable VERSION from RTEMS ./VERSION file.
* ./configure.in uses the macros from aclocal + support for the tools'
configure scripts
Remarks:
* To run rtems-polish.sh, "cd <rtems-source-tree>;
./c/update-tools/rtems-polish.sh"
* AFAIS, now all native subdirectories are converted to automake (Please
drop me a note, if I forgot something).
* Unless you notice something fatal, IMO the time has come for a public
try (== snapshot). I do not intend to send more automake related patches
within, say 2 weeks, to give these patches time to settle and to give me
some time to think on how to continue.
* The patch assumes installation to the new main installation directory
[$(prefix)].
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one once again changes the scheme to preinstall bsp_specs.
It moves generating PROJECT_ROOT/lib/bsp_specs to
libbsp/<cpu>/<bsp>/wrapup/Makefile.in.
I.e. it decentralizes generation of bsp_specs to a bsp-dependent
directory, because preinstalling bsp_specs in a centralized Makefile
like it has been done until now does not harmonize well with spliting
the toplevel configure script in cpu and bsp-dependent configure scripts
and automake.
First apply the patch (rtems-rc-19990318-0.diff) below, then run the
reorg-bsp_specs.sh script.
IMO, this one is comparatively harmless and eases automake support
significantly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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).
|
| |
|
|
|
| |
.s files to .S in conformance with GNU conventions. This is a
minor step along the way to supporting automake.
|
| |
|
|
|
| |
<jzamora@avellano.datsi.fi.upm.es>. He debugged enough to let me
know what was wrong and I supplied the code. :)
|
| |
|
|
| |
libchip, libio, and termios efforts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
made no attempt to divide the comments up and place them with just
the appropriate files. Here is an excerpt from Ralf's email:
Changes including comments on changes I made after cycling through
all the targets:
* Added ranlib support. Now all targets use "ranlib" instead of "ar -s"
to build an index for a library. If ranlib isn't detected during
configuration, check if ar -s is working and try "ar -s" instead of
* Removed $(XXX_FOR_TARGET) from make/target.cfg.in, use $(XXX) instead now.
* gcc-target-default.cfg: LINK_XXXX-defines reworked to solve the -l
problem under posix (cf gcc-target-default.cfg)
* rtems-glom replaced by Makefile-rules inside of the wrapup/Makefile.in
that has been using rtems-glom until now.
* Removed CCC and friends in gcc-target-default.cfg, as they have been
breaking CXX support.
* Removed CONFIG.$(TARGET_ARCH).CC lines from several custom/*.cfg
files, because this is now set in custom/default.cfg.
* Added aclocal/ar-s.m4, check whether "ar -s" is working
* Added aclocal/cygwin.m4 and aclocal/exeext.m4.
* Reworked aclocal/canonicalize-tools.m4: Added ar -s check; fixes for
problems when XXX_FOR_TARGET is given via environment variables (didn't
work for gcc until now), adding cygwin check, improved autoconf-cache
handling.
* Removed -l from make rule dependencies. LINK_LIBS is now allowed to
contain -L and -l. LINK_OBJS and LINK_FILES must not contain -L or -l.
gcc28 make-exe rules now link using $(LINK_OBJS) $(LINK_LIBS) => Almost
all custom/*.cfg are modified. This is very likely to break something
because of typos or having missed to edit a file.
Open problems, known bugs, things I didn't do:
* custom/p4000.cfg seems to be out of date and requires to be reviewed.
(JRS NOTE: It is subordinate p4650 and p4600 -- both of which build ok
after minor changes.)
* custom/psim.cfg needs to be reviewed, I added some changes to it, I am
insecure about.
(JRS NOTE: psim had a minor problem endif/endef swapped but runs fine.)
* rtems-glom.in can now be removed.
* gcc*.cfg files "make depend" rules don't honor language specific flags
(e.g CXXFLAGS is ignored for *.cc) - Nothing to worry about now, but may
cause problems for hosts/targets not using gcc or rtems-add-ons that use
external packages.
* AFAIS, the no_bsp BSP can't be build anymore, i.e. configure refused
to configure for it whatever I tried.
* The toplevel and toplevel+1 README files are quite out-dated
* cygwin.m4 isn't of much use for rtems. In most cases (cf.
aclocal/*.m4) it is worked around by directly using $host_os. I think
I'll remove it soon after the next snapshot
* Before release the cygwin patch needs to be tested under cygwin. I may
have broken/missed something (esp. the sed-pattern to convert \\ into /
may be broken).
* You should try to build/run the posix-BSP under solaris - I don't
expect problems, but I am not 100% sure, esp. with regard to ranlib/ar -s.
* You should consider to convert all make/compilers/*.cfg files into
make/compilers/*.cfg.in files and let autoconf generate the *.cfg. This
may help getting rid of some if/then/else statements and help
hard-coding some defines into those files in future and shouldn't
disturb now.
* Not having installed libc.a/libm.a on a host may still break building
rtems, esp. when using -disable-gcc28 as the gcc27-configuration scheme
directly accesses libc.a and libm.a. The problem should not appear when
using gcc28 because it references libc/libm only through -lc and -lm
which may be static or dynamic (I didn't test this).
* shgen is not yet included (I didn't yet have enough time to integrate it).
* I know about a few more configure-probs (esp. cross-checking
--enable-* flags).
+ warn/refuse to configure when --enable-libcdir and
--enable-gcc28 are given.
+ force --enable-libcdir when --disable-gcc28 is given
* Replaced KSHELL with @KSH@ in some shell scripts generated by configure.in.
* Added a dependency to aclocal/*.m4 in the toplevel Makefile => configure
and aclocal.m4 will now be rebuild when any aclocal/*.m4 file is changed
* Some changes to aclocal/gcc-pipe.m4 and aclocal/gcc-specs.m4
* Replaced i[[3456]]86-unknown-freebsd2.[[12]] with i[[3456]]86-*freebsd2.*
in configure.in, as I suppose there might exist a variety of valid vendors
(2nd field of the name-tripple)
* Disabled override MAKEFLAGS in toplevel Makefile.in - Potential
side-effects are not really clear to me.
* In mvme162.cfg, $(LINK_LIBS) is missing in the CC line in gcc28's make-exe
rule (yet another one I missed to edit). Just append $(LINK_LIBS) to
the "CC" line, like I hopefully did to ALL other custom/*.cfg files.
* the problem with mvme162lx.cfg is a follow-up problem of the
mvme162.cfg-bug.
* mvme162/console and idp/console had variables named Buffer which
conflicted with similarly named variables in some tests.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
code in each BSP's bspstart.c. These changes were:
+ confdefs.h now knows libio's semaphore requirements
+ shared/main.c now copies Configuration to BSP_Configuration
+ shared/main.c fills in the Cpu_table with default values
This removed the need for rtems_libio_config() and the constant
BSP_LIBIO_MAX_FDS in every BSP. Plus now the maximum number of open
files can now be set on the gcc command line.
|
| | |
|
| |
|
|
|
|
| |
to multiple. This lets the stack check extension be installed
at system initialization time and avoids the BSP having to
even know about its existence.
|
| | |
|
| |
|
|
| |
by newlib.
|
| |
|
|
| |
component.
|
| |
|
|
|
|
|
|
| |
based on the GNU tools. This usually involved correcting the
type of bsp_start(), bsp_cleanup(), adjusting the start code to
call the right start routine (the shared boot_card()), and then
removing code from bsp_start() which was performed in the new
boot_card()/main() path.
|
| | |
|
| | |
|
| |
|
|
| |
"gmake debug".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
> RTEMS is under CVS control and has been since rtems 3.1.16 which was
> around May 1995. So I just to add the $Id$. If you notice other files
> with missing $Id$'s let me know. I try to keep w\up with it.
Now that you have asked -- I'll attach a list of files lacking an RCS-Id to
this mail. This list has been generated by a little sh-script I'll also
enclose.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interpreted at the right point per Eric Norum's discovery:
The problem with the my previous `fix' for adding linker commands
was with the ordering of the options to the linker.
For example, to make a larger heap size, the application Makefile would
CFLAGS_LD = -Wl,--defsym -Wl,HeapSize=0x40000
The command passed to the linker would be :
m68k-rtems-ld .... -T xxx/linkcmds .... --defsym HeapSize=0x40000 .....
This doesn't work because the script in linkcmds inserts a default
value for HeapSize if HeapSize is not defined by the time the linker
looks at the linkcmds script.
The solution seems to be to move the -T linkcmds%s in the bsp_specs
file out of the link specfication and into the lib specification -- a
little unorthodox, perhaps, but it seems to work!
|
| |
|
|
| |
switch which lets the user specify a different linker script.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
four serial ports.
|
| | |
|
| | |
|
