incompatible versions of USB code in different FreeBSD releases (or even in
the same release makeworded on from sources cvsup'ed on different dates), so
that supporting all of them is nightmare.
I wish USB team would care about API compatibility in the future.
Submitted by: many
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.
o don't apply bitwise shift to components when setting palette - vgl don't
need it unlike fbcon (after which libvgl driver was modelled). Bump
PORTREVISION as a result of bugfix.
of libvgl. I abadoned my previous plans to get my extentions into the base
system because it seems that libvgl is at the end of its lifecycle and will
be replaced by more generic and better solution (probably kgi/ggi), at least
nsouch is actively working in this drection now. In the meantime, those
lucky with VESA 2.0 compatible videocards would be able to play quakeforge
or any other SDL-based games straight on their FreeBSD consoles ;).
all Makefile.in and as a result loosing some changes in the case when automake
is installed and detected by configure script.
PR: 24589
Reported by: Norikatsu Shigemura <nork@cityfujisawa.ne.jp>
and test it you need the following (5-CURRENT only, BTW):
- fetch a patch for libvgl: http://people.freebsd.org/~sobomax/libvgl.patch,
apply it, recompile/reinstall libvgl;
- recompile/reinstall sdl-devel (configure script automatically detects
if right version of libvgl is present);
- set environment variable SDL_VIDEODRIVER=vgl;
- ensure that you have VESA support compiled into kernel or loaded as a kld;
- fire up your favourite SDL app ;).
Starting from this release `sdl11-config --libs' output includes only SDL libs
and doesn't include X11 libs, which confuses configure scripts in third-party
apps. I reverted it to the previous behaviour.
XFree86 (3 or 4) to depend to when USE_XLIB is set.
XFREE86_VERSION defaults to 3 for now, but adventurous users can
override it in /etc/make.conf. When XFREE86_VERSION=3, USE_XLIB
will add a dependency to x11/XFree86; when it is set to 4, the
dependency will be to x11/XFree86-4-libraries. When
XFREE86_VERSION=4, the PKG_IGNORE_DEPENDS and ALWAYS_BUILD_DEPENDS
hacks to avoid messing with XFree86 are turned off.
Since XFree86 version 4 includes some software that used to be
separate ports, when XFREE86_VERSION=3 the following variables are
provided:
USE_DGS LIB_DEPENDS on x11/dgs
USE_FREETYPE LIB_DEPENDS on print/freetype
USE_MESA LIB_DEPENDS on graphics/Mesa3
USE_XPM LIB_DEPENDS on graphics/xpm
When XFREE86_VERSION=4, these variables have no effect. The
LIB_DEPENDS in the tree for the above four ports have all been
converted to the USE_* counterparts. For your information, this
is the count of the number of ports:
USE_DGS 0
USE_FREETYPE 16
USE_MESA 36
USE_XPM 236
There is a new variable, XAWVER, which is set to 6 when
XFREE86_VERSION=3 and 7 when XFREE86_VERSION=4. This is also
passed to PLIST_SUB so ports that build Xaw based shared libraries
can use this variable to substitute the shlib version number.
There is also a provision of using a separate mtree file for
XFREE86_VERSION=4, but that part is not enabled yet.
Reviewed by: the ports list
Tested by: make index (XFREE86_VERSION=3 only)
(2) Add hebrew to list of valid categories.
Submitted by: nbm
previous commit message to bsd.port.mk, which said INSTALL_SHLIBS. Boo.)
Line up the rhs of variable assignments nicely. Remove a couple of extra
whitespaces while I'm here.
Suggested by: sobomax
