107 lines
3.8 KiB
Plaintext
107 lines
3.8 KiB
Plaintext
# -*- text -*-
|
|
|
|
This is the official version of am-utils.
|
|
|
|
See the file NEWS for news on this and previous releases.
|
|
|
|
*** General Notes to alpha/beta testers:
|
|
|
|
[A] as alpha/beta testers, I expect you to be able to find certain things on
|
|
your own (especially look at the sources to figure out how things work).
|
|
|
|
[B] if you intend to modify any files, first find out if the file you want
|
|
to modify gets autogenerated from some other place. If so, modify it at the
|
|
source.
|
|
|
|
You can adjust some of the configuration of am-utils after it has been
|
|
auto-configured by putting whatever definitions you wish in a file called
|
|
localconfig.h, located in the top build directory (the same one where
|
|
config.h is created for you).
|
|
|
|
[C] there are several ways you can build am-utils:
|
|
|
|
(1) run the buildall script as follows:
|
|
|
|
./buildall
|
|
|
|
This would build all the applications inside a special directory relative to
|
|
the root of the source tree, called A.<cpu-company-system>, where the <>
|
|
part is filled in by GNU's config.guess script. This is the preferred
|
|
method, for it will separate the build from the sources, and allow you to
|
|
run buildall for multiple architectures concurrently.
|
|
|
|
You can run "buildall -h" to see what options it takes.
|
|
|
|
(2) run the configure script such as:
|
|
|
|
./configure
|
|
|
|
and then run
|
|
|
|
make
|
|
|
|
This would configure amd in the directory you've run the configure script
|
|
in, and the built it there. Run "make install" to install all the necessary
|
|
files.
|
|
|
|
Note that this is good for building only one version of amd on one
|
|
architecture! Don't try this for multiple architectures. If you must, then
|
|
after doing one such build, run "make distclean" and then reconfigure for
|
|
another architecture.
|
|
|
|
(3) run the configure script for build in a different location. Let's say
|
|
that /src/am-utils-6.0 is where you unpacked the sources. So you could
|
|
|
|
mkdir /src/build/sunos5
|
|
cd /src/build/sunos5
|
|
/src/am-utils-6.0/configure --srcdir=/src/am-utils-6.0
|
|
make
|
|
|
|
This is a manual method that will let you build in any directory outside the
|
|
am-utils source tree. It requires that your "make" program understand
|
|
VPATH. This can be used multiple times to build am-utils concurrently in
|
|
multiple (but different) directories. In fact, the buildall script
|
|
described above does precisely that, using the A.* subdirectories.
|
|
|
|
(4) If you need to configure am-utils with extra libraries and/or headers,
|
|
for example to add hesiod support, do so as follows:
|
|
|
|
configure --enable-libs="-lhesiod -lresolv" \
|
|
--enable-ldflags="-L/usr/local/hesiod/lib" \
|
|
--enable-cppflags="-I/usr/local/hesiod/include"
|
|
|
|
[D] If you modify any of the *.[chyl] sources in the directories amd, amq,
|
|
hlfsd, lib, etc, all you need to do to get a new version of am-utils is run
|
|
make.
|
|
|
|
If you modify any of the files in the aux/ or conf/ directories, or any *.in
|
|
or *.am file, then you must rebuild the configure script, Makefile.in files,
|
|
aclocal.m4, etc. The best way to do so is to run
|
|
|
|
./bootstrap
|
|
or
|
|
./buildall -K
|
|
|
|
To be a developer and be able to run "bootstrap", you must have
|
|
autoconf-2.50, automake-1.5, and libtool 1.4 installed on your system (or
|
|
later versions thereof). You no longer need to get my special version of
|
|
automake. Contact me if you'd like to be a maintainer and get access to the
|
|
CVS server.
|
|
|
|
After you've remade the basic configuration files you must rerun the
|
|
buildall script to rerun configure and then remake the binaries.
|
|
|
|
Modifying M4 macros may not be very intuitive to anyone that has not done so
|
|
before. Let me know if you are having any problems with them. I fully
|
|
expect, at least initially, to have to be the sole developers of the M4
|
|
macros and let others concentrate on C sources.
|
|
|
|
[E] Report all bugs to amd-dev@cs.columbia.edu. Avoid reporting to my
|
|
personal email address. It is important to involve the whole list in bug
|
|
fixes etc.
|
|
|
|
Good luck.
|
|
|
|
Erez Zadok,
|
|
Maintainer, am-utils.
|