|Age||Commit message (Collapse)||Author||Files||Lines|
(moving manuals to project repositories 16/19)
$(OSMO_GSM_MANUALS_DIR) is used in most places to reference to the top
dir, which contains "build" and "common". But not in the asciidoc
mscgen filter configurations, and in the custom LaTeX style. They have
../common or ../build hardcoded, which won't work anymore when the
project specific files will be in another repository.
Update the Makefiles to create symlinks to "build" and "common" in the
dir where the build was started. Use ./common in the files that had
../common hardcoded, and do the same for ./build.
Update the Makefile.common.inc comment to refer to common targets in
general, so we don't need to list each single one there (like the new
'common' and 'build' targets).
I've also thought about using variables there, but this would only work
for the asciidoc files, not for the .sty file. We would need to
generate the latter from another file and replace the variable
dynamically. Having the symlinks instead seemed to be slightly easier.
(moving manuals to project repositories 7/19)
For reasoning why a transition to autotools is desired, see the commit
message of the previous patch in this series.
"make install" copies the "build", "common" dirs, as well as the "*.xsl"
files to $(prefix)/share/osmo-gsm-manuals. Prefix is typically
/usr/local. Also a pkg-config file gets installed, so the path of the
shared files can be looked up by autoconf scripts of the project
repositories. The check-depends script is installed to
$(prefix)/bin/osmo-gsm-manuals-check-depends and will be used by
project specific autoconf scripts, too.
All existing make targets ("make", "make check", "make upload") are
still working, users only need to run "autoreconf -fi" and
Makefile.am uses custom install-data-hook and uninstall-local targets,
so we don't need to specify each file of the relevant subdirs in a
_DATA variable (no extra maintenance effort).
(moving manuals to project repositories 5/19)
Add the same version of git-version-gen, which most other Osmocom
repositories (libasn1c, libosmocore, libosmo-netif, libosmo-sccp, ...)
are using, so they behave the same.
git-version-gen generates a version string derived from the git
repository, or from a .tarball-version file when running outside of a
git directory. Unfortunatelly it seems to be impossible to use
git-version-gen from autoconf without adding it to the source tree.
Autotools will be used to install the shared manual files into the
system in a way that is consistent with the other Osmocom repositories:
$ autoreconf -fi
$ ./configure --prefix=/usr/local
$ make install
Project repositories will check with pkg-config if osmo-gsm-manuals is
installed (like any other shared Osmocom component), when a new
configure flag for building the manuals is passed. This will also work
with distribution's package managers, for instance we could have a
osmo-gsm-manuals-dev package in Debian on which the other packages
would have a build-time dependency to build the UNIX man pages
(moving manuals to project repositories 4/19)
Build project independent "test-usermanual.pdf" (with all common
chapters automatically included) and "test-vty-reference.pdf" files.
This allows testing if changed common chapters and the build scripts
are still working, even when the project specific manuals will be moved
away from this repository.
(moving manuals to project repositories 2/19)
Generate *.check files from asciidoc output and grep for WARNINGs.
Add *.check files to gitignore and to 'make clean'.
The manuals existed in different form for several years in an internal
sysmocom repository. However, since they had just recently been
converted from docboox-xml to asciidoc and all files have been
re-shuffled for enabling the public release, there's not much point in
keeping the history with git-filter-branch.