-Update libtool and libltdl to 2.2.6a.
-Remove devel/libtool15 and devel/libltdl15.
-Fix ports build with libtool22/libltdl22.
-Bump ports that depend on libltdl22 due to shared library version change.
-Explain what to do update in the UPDATING.
It has been tested with GNOME2, XFCE4, KDE3, KDE4 and other many wm/desktop
and applications in the runtime.
With help: marcus and kwm
Pointyhat-exp: a few times by pav
Tested by: pgollucci, "Romain Tartière" <romain@blogreen.org>, and
a few MarcusCom CVS users. Also, I might have missed a few.
Repocopy by: marcus
Approved by: portmgr
Specifically, newer autoconf (> 2.13) has different semantic of the
configure target. In short, one should use --build=CONFIGURE_TARGET
instead of CONFIGURE_TARGET directly. Otherwise, you will get a warning
and the old semantic may be removed in later autoconf releases.
To workaround this issue, many ports hack the CONFIGURE_TARGET variable
so that it contains the ``--build='' prefix.
To solve this issue, under the fact that some ports still have
configure script generated by the old autoconf, we use runtime detection
in the do-configure target so that the proper argument can be used.
Changes to Mk/*:
- Add runtime detection magic in bsd.port.mk
- Remove CONFIGURE_TARGET hack in various bsd.*.mk
- USE_GNOME=gnometarget is now an no-op
Changes to individual ports, other than removing the CONFIGURE_TARGET hack:
= pkg-plist changed (due to the ugly CONFIGURE_TARGET prefix in * executables)
- comms/gnuradio
- science/abinit
- science/elmer-fem
- science/elmer-matc
- science/elmer-meshgen2d
- science/elmerfront
- science/elmerpost
= use x86_64 as ARCH
- devel/g-wrap
= other changes
- print/magicfilter
GNU_CONFIGURE -> HAS_CONFIGURE since it's not generated by autoconf
Total # of ports modified: 1,027
Total # of ports affected: ~7,000 (set GNU_CONFIGURE to yes)
PR: 126524 (obsoletes 52917)
Submitted by: rafan
Tested on: two pointyhat 7-amd64 exp runs (by pav)
Approved by: portmgr (pav)
in bsd.autotools.mk essentially makes this a no-op given that all the
old variables set a USE_AUTOTOOLS_COMPAT variable, which is parsed in
exactly the same way as USE_AUTOTOOLS itself.
Moreover, USE_AUTOTOOLS has already been extensively tested by the GNOME
team -- all GNOME 2.12.x ports use it.
Preliminary documentation can be found at:
http://people.FreeBSD.org/~ade/autotools.txt
which is in the process of being SGMLized before introduction into the
Porters Handbook.
Light blue touch-paper. Run.
Cal3D is a skeletal based 3D character animation library written in C++
in a way that is both platform-independent and graphics API-independent.
It was originally designed to be used in a 3D client for Worldforge, but
evolved into a stand-alone product which can be used in many different
kinds of projects.
Cal3D's essentials can be boiled down to 2 parts: the C++ library and
the exporter. The exporter is what you would use to take your characters
(built in a 3D modeling package) and create the Cal3D-format files that
the library knows how to load. The exporters are actually plug-ins for
3D modeling packages. This allows 3D artists to use the modeling tools
that they're already comfortable with.
The C++ library is what you would actually use in your application,
whether it's a game or a VR application. The library provides methods to
load your exported files, build characters, run animations, and access
the data necessary to render them with 3D graphics.
WWW: http://cal3d.sourceforge.net/
Add CONFLICTS in graphics/cal3d
PR: 88536
Submitted by: Jose Alonso Cardenas Marquez <acardenas@bsd.org.pe>
Repocopy by: marcus
also fixes a problem with the packing list (libdata/pkgconfig would be
created by the port but not removed by it, now it will be done by the
pkgconfig port).
PR: 75119
Submitted by: Stefan Walter <sw@gegenunendlich.de> (maintainer)
Cal3D is a skeletal based 3D character animation library
written in C++ in a way that is both platform-independent and
graphics API-independent. It was originally designed to be
used in a 3D client for Worldforge, but evolved into a
stand-alone product which can be used in many different kinds
of projects.
Cal3D's essentials can be boiled down to 2 parts: the C++
library and the exporter. The exporter is what you would use to
take your characters (built in a 3D modeling package) and
create the Cal3D-format files that the library knows how to
load. The exporters are actually plug-ins for 3D modeling
packages. This allows 3D artists to use the modeling tools that
they're already comfortable with.
The C++ library is what you would actually use in your
application, whether it's a game or a VR application. The
library provides methods to load your exported files, build
characters, run animations, and access the data necessary to
render them with 3D graphics.
PR: ports/68954
Submitted by: Stefan Walter <sw@gegenunendlich.de>
