* Makefile.am, develenv.texi: Relect generating .texi from .t's.
* direct.t, sample.t, utils.t: New files.
* direct.texi, sample.texi, utils.texi: Removed. Now generated from
corresponding .t files which are in the process of being updated.
This commit is a anspshot of the update effort.
* SUPPORT, LICENSE: New files.
* Numerous files touched as part of merging the 4.5 branch
onto the mainline development trunk and ensuring that the
script that cuts snapshots and releases works on the documentation.
<corsepiu@faw.uni-ulm.de> which:
* should fix the building rtemsdoc outside of the sourcetree with
relative srcdir issue
* adds --enable-papersize=[letter|a4|]
which splits the current monolithic specs files into a sequence of
subparts. These can be concatenated togather to make a the whole .spec
file. This cleans up the maintenance problem of having "all languages"
and a "C/C++ only" gccnewlib spec files. Plus it should make it easier
to produce variants like the gdb-m68k-bdm which require special hackery. :)
Ralf's comments:
It addresses the way *.spec.in get composed inside of the source
tree.
Changes:
* Each spec.in is broken into several files (*.add), one *.add file
per sub-package.
* Each Makefile.am composes spec.ins from the *.add files
* Removal of redundant automake support files.
* Default value for BuildRoot changed to /tmp/<spec-file-name>
* %clean stage added to *specs
Advantages (IMHO).
* The *.add files are easier to adminstrate and more flexible in
comparison to the former *.specs.ins.
* gccnewlib_c_only.spec.in now is composed from the same sources as
gccnewlib.spec.in (less errors)
* If using the default BuildRoot --clean now deletes all files that
were generated while building.
Notes:
* rtems.spec.in has not yet been adapted to the scheme used for the
other *spec.ins
* Except for cosmetical changes the internals of the *.spec files
should not have changed.
To Apply:
cvs rm -f scripts/binutils/binutils.spec.in
cvs rm -f scripts/gccnewlib/gccnewlib.spec.in
cvs rm -f scripts/gccnewlib/gccnewlib_c_only.spec.in
cvs rm -f scripts/gdb/gdb.spec.in
cvs rm -f scripts/config.sub
cvs rm -f scripts/config.guess
cvs rm -f scripts/install-sh
cvs rm -f scripts/mkinstalldirs
cvs rm -f scripts/missing
patch -p1 < rtems-rc-4.5.0-21.diff
cvs add scripts/*/*.add
cvs add scripts/*/README
Ralf's comments follow:
Changes:
* Enhanced versioning:
- Addition of automake's version.texi support
- Replacement of rtemsdoc's former versioning support by automake's
versioning support (Abandoning RTEMS-UPDATE-* etc.)
- Abandoning setup.texi.in
- Add EDITION to each documents Makefile.am
- version.texi support in project.am
- Addition of maintainer mode (currently only used to prevent incorrectly
updating timestamps when users touch automake's version.texi timestamp
files (stamp-vti)).
* Fixing info dir support
- Use texinfo's @dircategory and @direntry instead of infos *-DIR-ENTRY
- $(infodir)/dir is now correctly set up
* Avoid using temporary files
- Pipe texts through REPLACE2 into BMENU2 instead of using temporary files.
- Abandon using bmenu in favor of bmenu2 (bmenu could be removed now)
* Prepare Makefile.ams for building in a separate buildtree
- prefix files with $(srcdir) in Makefile.am for files which must be
generated inside of the source tree
Notes:
* rtemsdoc can not yet be build in a separate source-tree, but we
are very close to it.
* You as the maintainer of this package now should always use
--enable-maintainer-mode to configure rtemsdoc.
It addresses:
* .cvsignore (only minor changes to yours, as they were pretty clean,
most changes result from my mkcvsignore script being overly pedantic
sorting entries alphabetically.)
* timing.t handling and time<BSP>_.texi handling in supplements
* network.t handling in bsp_howto
* RTEMS_DATE and RTEMS_UPDATE handling in configure.in. [It actually is
a hack, as we could apply automake's version.texi handling instead - I
know think to understand what automake does with it.]
* avoid using temporary files; Therefore a new tool called bmenu2,
derived from bemenu, is introduced, which reads a single file from stdin
and writes to stdio.
To apply:
cd rtemsdoc
patch -p1 < rtemsdoc-4.5.0-rc-3.diff
cvs rm -f bsp_howto/network.t
cvs add tools/bmenu/bmenu2.c
./bootstrap
BTW: word-replace now is unused. It could be removed if you like to.
which contains the bulk of converting the documentation tree to automake
and GNU conventions. Comments follow:
This is the automake port of rtemsdoc.
To apply:
cvs co rtemsdoc
cd rtemsdoc
sh cvs-rm.sh
patch -p0 < rtemsdoc-4.5.0-rc-0.diff
sh cvs-add.sh
[Attention: cvs-rm.sh and cvs-add.sh directly modify cvs]
Known bugs:
1) src2html is not supported (yet? - Is this supposed to work?)
2) all *.pdf images now are generated on-the-fly, but not yet deleted
during "make distclean"
3) All supplements, including the templated ones, get build and
installed.
4) Building outside of the source tree is completely untested and very
likely does not work.
5) Make [ps|pdf] are not (yet) supported, make [dvi|info] are supported
by automake's default texinfo rules.
Fixing 2, 3 and 5 is almost trivial and needs to be done.
4) is a matter of testing and tool-properties, for now it is simply
untested.
General issues:
* gif vs jpg vs png. I would recommend to replace all images with pngs
to avoid potential copyright issues (gif) or lack in quality (jpg, jpg
is good for real world photographs, but extremely poor on artificial
images, graphs).
* pdf images do net get placed correctly in pdf-documents.
* texinfo: We now use a local copy of texinfo-4.0's texinfo.tex in
texinfo/texinfo.tex for generating infos. However pdftex's system-wide
texinfo.tex and pdftexinfo.tex are used for generating *.dvi, *.ps, *.pdf.
* .cvsignore files still missing.
* I have renamed the supplements filename not to use c_<supplement>,
because automake seems to have problems with it.
Notes:
* Again, I recommend not to put any generated files into CVS. Here, this
comprises some *texi, all *.pdf and many *.html pages. Ie. I recommend
to run make maintainer-clean before checking in any files.
* To get building started, this should be sufficient:
./bootstrap
./configure
cd tools; make; cd ..
make info
* To make a public tarball:
[cvs co ; ./bootstrap]
./configure
cd tools; make; cd ..
make info
[make clean]
make dist
=> This generates a rtems-<version>.tar.gz in the toplevel directory.
=> Building the tools only is required after a "cvs co", but not in a
distribution tarball.
