Instead of trying to patch it, just supply a BSD-specific Makefile
using <bsd.prog.mk>. This removes the build-time dependency of this
tiny port on USE_REINPLACE and the heavy-weight gmake at once.
subvert the 'check_pid_file' procname check by setting it from the output
of 'ps'.
Remove the previous attempt at handling this problem, which was to put
a wildcard in procname. I'll wear my pointy hat for that bogus hack.
Reported by: Fritz Heinrichmeyer <Fritz.Heinrichmeyer@FernUni-Hagen.de>
- Fix pkg-message
- Remove redundant code from a startup script
- Install a sample config in EXAMPLESDIR instead of PREFIX/etc
- Refine pkg-descr a little
o Currently unmaintained, will take maintainership
o Clean-up Makefile
- Use PORTDOCS macro and DATADIR
- Dependency on glut implies X libraries
o Change pkg-message to pkg-message.in so DATADIR and DOCSDIR variables can
be used
o Patch for joystick support
o Update WWW
PR: ports/92930
Submitted by: Jason E. Hale <bsdkaffee@gmail.com>
- Add 'graphics' category [2]
- Move RUN_DEPENDS [2]
- Use USE_ANT
- JAVAJARDIR -> JAVALIBDIR
- Do not set JAVA_BUILD/JAVA_RUN, just set NO_BUILD when needed
- Cleanup: remove now useless PLIST_SUB entries
- ECHO_CMD -> ECHO_MSG
- Trim whitespaces in pkg-descr
Reported by: thierry [1], portlint [2]
this port installs encodings, try to remove them upon uninstallation, so
removing of directories has a chance to succeed. Just in case some user
has for some reason put fonts under these directories, be nice and try to
regenerate cache file and remove it again only if it is empty.
On installation try running fc-cache for directory where fonts from this
port are installed and don't complain if fc-cache (from fontconfig) is
missing. Do a bit more dancing on uninstall, just in case users have their
own fonts installed in same directory:
- first remove fonts.cache-1 if it is there since it won't be accurate
after fonts from this port are gone anyway,
- next try to regenerate cache with fc-cache for this directory
- if previous step generates empty cache file, remove it
If directory contained only fonts from this port, it should get properly
removed at the end. If there were other fonts there and fontconfig is
installed, this will leave proper cache file for remaining fonts behind
after uninstall of this port.
These changes apply to all ports, unless mentioned otherwise:
- Move jakarta-tomcat55 to tomcat55 (it is no longer a Jakarta project). [6]
- Improve the tomcat55 rc script. Fix PID handling. Improve the
shutdown process. Use USE_RC_SUBR to its full potential. [2]
- Backport tomcat55 rc script to the other tomcat ports. This allows
us to pass command line arguments to the JVM. Noted in UPDATING.
[1], [3], [4]
- Change ownership of installed files. All files are now installed
with default uid/gid (root:wheel) except for those in the conf/, logs/,
temp/ and work/ directories. [5]
- No longer install tomcatXXctl binary. rc scripts are more flexible
and can be reconfigured without recompiling.
- Remove AUTO_START and STOP_TIMEOUT (replaced with rc tomcatXX_stop_timeout).
- Remove a long list of sed expressions in favour of SUB_LIST.
- Move pkg_{,de}install to files/pkg_{,de}install.in. Add them to
SUB_FILES. Tidy up substitutions and remove hardcoded values.
- Some nonfunctional tidying and removal of Makefile cruft.
PR: ports/38018 [1], ports/38020 [2], ports/74344 [3],
ports/75143 [4], ports/83434 [5], ports/92692 [6]
Submitted by: Ari Suutari <ari.suutari@syncrontech.com> [1] [2],
SimpleRezo Team <freebsd@simplerezo.com> [3],
Anton Yudin <toha@toha.org.ua> [4],
Jan Grant <jan.grant@bristol.ac.uk> [5],
lawrance [6]
Approved by: Kang Liu <liukang@cn.freebsd.org> (maintainer) [6]
Maintainer timeouts on [1], [2], [3], [4], [5]
Big thanks to: hq for the initial tomcat55 script
jasonb on FreeNode #tomcat for packaging advice
- Add 'devel' category
- Use USE_ANT
- Do not set JAVA_BUILD/JAVA_RUN, just set NO_BUILD when needed
- Cleanup: remove now useless PLIST_SUB entries
- ECHO_CMD -> ECHO_MSG
- The port now installs another JAR file: jcommon-xml.jar
Tested by: thierry
formally been released yet, but it's very close and Fortran support is so
much better than in the latter, that this seems appropriate.
This is also based on concrete recommendations by a GFortran developer and
a user based on their experiences.
