On the way, upgrade to the 20050819 snapshot of GCC 4.1 where the Java
libraries finally build (progress!) but fail due to a problem with the
installation. If someone wants to force installation, setting SHAREMODE
to allow writing should suffice.
Approved by: portmgr (krion)
on sparc64 and -fpic elsewhere. While here, make the following
improvements:
. ignore the vendor's fdlibm and use our own -lm. fdlibm is
derived from the same msun as ours, but spidermonkey was
misteriously linking with _both_. All mozilla-ports seem
to have the same problem right now;
. use our -lreadline instead of compiling vendor's own
libeditline;
. fix all warnings (clean build with -Wall -Werror);
. link the installed executable (js) against the shared
library libjs.so instead of against the invididual objects;
. unless WITHOUT_TEST is set, download and run vendor's own
tests in post-build (this triggers USE_PERL_BUILD). Some
tests had to be patched from Mozilla's CVS, because the
released tarball of them was not updated since 2002.
Bump PORTREVISION.
Approved by: portmgr (marcus)
Approved by: maintainer timeout
- Add a file that was not included in the package
- Remove offending "@unexec rm" lines that masked the problem
- Bump PORTREVISION
Approved by: portmgr (clement)
Replace the WITHOUT_LIBJAVA knob by WITHOUT_JAVA which also disables
building the compiler and tools proper and avoids fetching the entire
Java frontend and library tarball.
Remove bogus ${PREFIX}/share/classpath/api directory that libjava adds
these days.
Make the (optional) handling of the Fortran and Java frontends easier
to understand.
be bound to a Java Tag which is a Java bean that performs some function.
Jelly is totally extendable via custom actions (in a similar way to JSP custom
tags) as well as cleanly integrating with scripting languages such as Jexl,
Velocity, pnuts, beanshell and via BSF (Bean Scripting Framework) languages
like JavaScript & JPython.
Jelly uses an XMLOutput class which extends SAX ContentHandler to output XML
events. This makes Jelly ideal for XML content generation, SOAP scripting or
dynamic web site generation. A single Jelly tag can produce, consume, filter or
transform XML events. This leads to a powerful XML pipeline engine similar in
some ways to Cocoon.
WWW: http://jakarta.apache.org/commons/jelly/index.html
(even ones it is supposed to work on, cf. pointyhat), it fails to build
on FreeBSD 6 and 7, and lang/gcc32 is basically the same plus a single
ABI changes and many bug fixes.
It is strongly recommended to migrate to GCC 3.4 or 4.0, since only these
are still actively maintained upstream and support FreeBSD 7, for example.
