Commit Graph

8 Commits

Author SHA1 Message Date
Sebastian Huber
c1e98cd45a Resurrect make/Templates/Makefile.lib
This file was accidentally removed by
370c09a1f4.
2015-11-05 11:51:20 +01:00
Isaac Gutekunst
370c09a1f4 Add STM32F4 HAL Files
The origin of this code is:
   + STM32CubeF4 V1.8.0 from http://www.st.com/web/en/catalog/tools/PF259243
2015-11-03 17:31:07 -06:00
Joel Sherrill
65c6425de9 Remove CVS Id Strings (manual edits after script)
These modifications were required by hand after running the script.
In some cases, the file names did not match patterns. In others,
the format of the file did not match any common patterns.
2012-05-11 08:44:14 -05:00
Joel Sherrill
df49c60c96 Merged from 4.5.0-beta3a 2000-06-12 15:00:15 +00:00
Joel Sherrill
8548fe0ae2 Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:
> 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).
1999-02-18 18:36:05 +00:00
Joel Sherrill
01629105c2 Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de> to rename all
.s files to .S in conformance with GNU conventions.  This is a
minor step along the way to supporting automake.
1998-12-14 23:15:38 +00:00
Joel Sherrill
5c3511e5cf Big patch form Ralf Corsepius described in this email:
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
1998-01-30 21:49:51 +00:00
Joel Sherrill
bffb938799 Removed PROJECT_HOME and CONFIG_DIR variables. 1998-01-20 19:30:30 +00:00