GigaBASE: Object-Relational Database Management System
GigaBASE inherits most of the features of FastDB, but uses page pool
instead of direct mapping of file on virtual memory. So GigaBASE is able
to handle database, which size significantly exceeds size of computer
physical memory. Convenient and flexible C++ interface makes development
of application for GigaBASE very easy and automatic scheme evaluation
simplifies maintenance and modification of the system. GigaBASE merges
best features of relational (simple data structure and non-procedural
query language) and object-oriented (direct object references, user
defined types and methods) databases. GigaBASE is primary oriented on
application requiring fast data retrieving by means of indices and
direct object references, such as Web Server databases applications.
SUBSQL utility can be used for database browsing and inspection,
performing online backups, database recovery, importing data to and
exporting data from database. GigaBASE will perform automatic recovery
after system or application crash, you should not worry about it. The
only thing you can have to do manually is stopping all database
application if one of them is crashed leaving database blocked.
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
Add WWW entries to port Makefiles
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
(Only the first 15 lines of the commit message are shown above )
*/*: Replace USE_GCC=any with USE_GCC=yes
USE_GCC=any has been equivalent to USE_GCC=yes in most cases (such
as i386 and amd64 since 12.x and depending on configuration 11.x,
most newer installations on other platforms, and 13.x across the
board).
Since commit 96c17633d90386b5bcf8 Mk/bsd.gcc.mk is treating them as
different spellings of the same, so continue the deorbiting of the
USE_GCC=any form and simply replace it with USE_GCC=yes.
This should not make any functional difference at all.
Discussed with: mat, linimon, pkubaj
Bump PORTREVISION for ports depending on the canonical version of GCC
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Bump PORTREVISION for ports depending on the canonical version of GCC
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Bump PORTREVISION for ports depending on the canonical version of GCC
in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which
has now moved from GCC 6 to GCC 7 by default.
This includes ports
- featuring USE_GCC=yes or USE_GCC=any,
- featuring USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and those
- with USES=compiler specifying one of openmp, nestedfct, c11, c++0x,
c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib.
PR: 222542
Bump PORTREVISION for ports depending on the canonical version of GCC
(via Mk/bsd.default-versions.mk and lang/gcc) which has moved from
GCC 5.4 to GCC 6.4 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++11-lang,
c++14-lang, c++0x, c11, or gcc-c++11-lib.
PR: 219275
databases/gigabase: work around GCC >= 6 bustage
testtimeseries.cpp: In function 'float fmax(float, float)':
testtimeseries.cpp:50:35: error: 'float fmax(float, float)' conflicts with a
previous declaration
inline float fmax(float x, float y) { return x > y ? x : y; }
^
In file included from /usr/local/lib/gcc6/include/c++/math.h:36:0,
from testtimeseries.cpp:15:
/usr/local/lib/gcc6/include/c++/cmath:1452:3: note: previous declaration
'constexpr float std::fmax(float, float)'
fmax(float __x, float __y)
^~~~
testtimeseries.cpp: In function 'float fmin(float, float)':
testtimeseries.cpp:51:35: error: 'float fmin(float, float)' conflicts with a
previous declaration
inline float fmin(float x, float y) { return x < y ? x : y; }
^
(Only the first 15 lines of the commit message are shown above )
Bump PORTREVISIONs for ports depending on the canonical version of GCC and
lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using using Mk/bsd.octave.mk which in turn has USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
c++11-lang, c++0x, c11, or gcc-c++11-lib.
PR: 216707
Bump PORTREVISIONS for ports depending on the canonical version of GCC and
lang/gcc which have moved from GCC 4.8.5 to GCC 4.9.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
In particular that is ports with USE_GCC=yes, USE_GCC=any, or one of
gcc-c++11-lib, openmp, nestedfct, c++11-lib as well as c++14-lang,
c++11-lang, c++0x, c11 requested via USES=compiler.
- Add LDFLAGS to CONFIGURE_ENV and MAKE_ENV (as it was done with LDFLAGS)
- Fix all ports that add {CPP,LD}FLAGS to *_ENV to modify flags instead
PR: 157936
Submitted by: myself
Exp-runs by: pav
Approved by: pav
Remove USE_GNOME=gnometarget from ports. It has been a empty keyword since
mid 2008.
PR: ports/159624
Submitted by: Ruslan Mahmatkhanov <cvs-src@yandex.ru>
-Repocopy devel/libtool15 -> libtool22 and libltdl15 -> libltdl22.
-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
Mass-conversion to the USE_AUTOTOOLS New World Order. The code present
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.
Update to latest release 3.22.
From CHANGES:
<quote>
1. Introduce area_t type to specify type used for rectangle
coordinates multiplication (spatial index)
2. Fix critical bug in query deallocation synchronization
(which can cause crash in mu tithreaded environment)
</quote>
Whoa there, boy, that's a mighty big commit y'all have there...
Begin autotools sanitization sequence by requiring ports to explicitly
specify which version of {libtool,autoconf,automake} they need, erasing
the concept of a "system default".
For ports-in-waiting:
USE_LIBTOOL=YES -> USE_LIBTOOL_VER=13
USE_AUTOCONF=YES -> USE_AUTOCONF_VER=213
USE_AUTOMAKE=YES -> USE_AUTOMAKE_VER=14
Ports attempting to use the old style system after June 1st 2004 will be
sorely disappointed.
