From submitter:
* Unmark BROKEN for 64-bit architectures: developers report that it works fine
(not tested, I only have i386).
* Instead of patching makemake.in, specify correct location of mandir via
./makemake option.
* Add build dependency on libsigsegv for better garbage collection.
* Update pkg-descr per request from developers.
PR: ports/85677
Submitted by: Jakub Rehor <jakub@rehor.net> (maintainer)
problems should be resolved now.
Prevent running ranlib during installation to unbreak user mode
installations which now install libraries with permissions 444.
We now also need the math/mpfr port to build the Fortran frontend.[1]
PR: 85495 [1]
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
