106 lines
3.7 KiB
Plaintext
106 lines
3.7 KiB
Plaintext
|
# -*- text -*-
|
||
|
|
||
|
This is an alpha version of amd. "Buyers" beware!!!
|
||
|
|
||
|
See the file NEWS for news on this and previous releases.
|
||
|
|
||
|
*** General Notes to alpha testers:
|
||
|
|
||
|
[A] an an alpha 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.
|
||
|
|
||
|
(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, then you
|
||
|
must rebuild the configure script, Makefile.in files, aclocal.m4, etc. The
|
||
|
best way to do so is to run
|
||
|
|
||
|
./aux/mkconf
|
||
|
or
|
||
|
./buildall -K
|
||
|
|
||
|
To be a developer and be able to run mkconf, you must have autoconf-2.12,
|
||
|
GNU make-3.75 or later, and automake-1.2 (plus my fixes to it) installed on
|
||
|
your system. You may find my version of automake-1.2 where you ftp'ed this
|
||
|
version of am-utils. You may also need GNU libtool 1.0.
|
||
|
|
||
|
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@majordomo.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.
|