Remove my code to handle the documentation merge for patched releases, it
was rather obscure and error-prone. I'll rewrite it in a simpler way next
time I'll need to perform the merge.
Also include a fix for erlang-mode under emacs21 (by Hal Snyder
<hal@vailsys.com> on the erlang mailing list).
the ECHO macro is set to "echo" by default, but it is set to "true" if
make(1) is invoked with the -s option while ECHO_CMD is always set to
the echo command.
Use command macros where appropriate.
A detailed changelog is available at:
http://www.erlang.org/download/otp_src_R7B-2.readme
(NOTICE: there is an incompatibility with the previous version: see
OTP-3744)
Port note: I finally removed all the lib/ files from pkg-plist, and
switched to automatic plist generation because Erlang is so nice as to live
in its own subdirectory. Previous plist management involved far too many
%%HACKS%%, and untold hours of compilation/testing to get every combination
right.
* Put documentation in the correct directories.
An UPDATED_PACKAGES variable is provided in the Makefile to select which
documentation should be moved (see Makefile comments).
* Move man pages out of pkg-plist.
* Add man pages to Makefile.
* Don't compress man pages, to support emacs erlang mode.
* Don't try to compile java dependent packages if javac cannot be found:
tell user to check JAVABINDIR in this case.
(no functional changes to the base Erlang system)
Maintainer: timed out
FWIW, checkout of these things took 5+hrs, staying on the local
.freebsd.org net w/o hitting the 'net at all.
As promised,
$ time cvs ci
real 67m51.701s
user 0m1.250s
sys 0m5.345s
${MACHINE_ARCH}--freebsd${OSREL} is now passed to CONFIGURE_ARGS if
GNU_CONFIGURE is defined. Take the target out of CONFIGURE_ARGS of
some ports that added it explicitly; define it as
${MACHINE_ARCH}--freebsd if the port doesn't like the ${OSREL} part;
define it as something else (such as ${MACHINE_ARCH}--freebsdelf if
the port requires that; define it as an empty string if the port
doesn't like it at all.
The last might be a sign that a GNU_CONFIGURE port actually doesn't
use GNU's version of configure at all; but I don't have time to go
look at them all, we'll fix them as time goes on.
At least we've got much fewer "-unknown-"s in the tree as the result. :)
