Silo is a library for reading and writing a wide variety of scientific
data to binary, disk files. The files Silo produces and the data within
them can be easily shared and exchanged between wholly independently
developed applications running on disparate computing platforms.
Consequently, Silo facilitates the development of general purpose tools
for processing scientific data.
===> The following configuration options are available for silo-4.12.1_1:
BROWSER=on: Enable building of browser
FORTRAN=on: Fortran language support
HDF5=on: HDF-5 data format support
PYTHON=on: Python bindings or support
SILOCK=on: Enable building of silock
===> Use 'make config' to modify these settings
science/silo: fix build with clang 15
During an exp-run for llvm 15 (see bug 265425), it turned out that
science/silo failed to build with clang 15:
/wrkdirs/usr/ports/science/silo/work/Silo-4.11-68-g819658e/src/hdf5_drv/silo_hdf5.c:1869:13:
error: incompatible integer to pointer conversion passing 'char' to parameter of
type 'const char *'; take the address with & [-Wint-conversion]
DB_OBJ_CASE(DB_CURVE, DBcurve_mt, npts?1:1, yvarname)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/science/silo/work/Silo-4.11-68-g819658e/src/hdf5_drv/silo_hdf5.c:1812:36:
note: expanded from macro 'DB_OBJ_CASE'
(*dsnames)[i] = strdup(m.MEMNAME[i]); \
~~~~~~~^~~~~~~~~~~~~
/wrkdirs/usr/ports/science/silo/work/Silo-4.11-68-g819658e/src/silo/silo_private.h:939:35:
note: expanded from macro 'strdup'
#define strdup(s) _db_safe_strdup(s)
^
/wrkdirs/usr/ports/science/silo/work/.build/include/silo.h:2214:68: note:
passing argument to parameter here
SILO_API extern char * _db_safe_strdup(const char *);
^
This turns out to be a bug in silo, which I reported upstream in
https://github.com/LLNL/Silo/issues/296, and which was fixed in
https://github.com/LLNL/Silo/commit/be29ddf.
PR: 268864
Approved by: yuri (maintainer)
MFH: 2023Q1
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 )
science/hdf5: bump PORTREVISION of consumers
The SO-version increased in the update to 1.12.2 in
a43418b81530f7e897abfbe18dd59f44265a1a0f .
Reported by: VVD <vvd@unislabs.com>
science: remove 'Created by' lines
A big Thank You to the original contributors of these ports:
* Andreas Fehlner <fehlner@gmx.de>
* Brad Huntting <huntting@glarp.com>
* Chao Shin <quakelee@cn.FreeBSD.org>
* Cheng-Lung Sung <clsung@FreeBSD.org>
* Chia-Hsing Yu <me@davidyu.org>
* Chris Rees <utisoft@gmail.com>
* David Naylor <dbn@FreeBSD.org>
* Dmitry Sivachenko <demon@FreeBSD.org>
* Ed Schouten <ed@FreeBSD.org>
* Eric Freeman <freebsdports@chillibear.com>
* Erik B Knudsen
(Only the first 15 lines of the commit message are shown above )
Fix CONFLICTS entries of multiple ports
There have been lots of missing CONFLICTS_INSTALL entries, either
because conflicting ports were added without updating existing ports,
due to name changes of generated packages, due to mis-understanding
the format and semantics of the conflicts entries, or just due to
typoes in package names.
This patch is the result of a comparison of all files contained in
the official packages with each other. This comparison was based on
packages built with default options and may therefore have missed
further conflicts with optionally installed files.
Where possible, version numbers in conflicts entries have been
generalized, some times taking advantage of the fact that a port
(Only the first 15 lines of the commit message are shown above )
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
Related to revision 499061 bump ports with USES=fortran to have them
benefit from the improved situation where libgcc_s is only used when
absolutely necessary.
Suggested by: tijl
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
Mark QT4 ports/functionality for removal on 2019-03-15
While here, chase some KDE4 ports and functionality, these are scheduled for
removal on 2018-12-31. Change the default option/flavor to QT5 where applicable
or use alternative toolkits like GTK.
Submitted by: tcberner
Reviewed by: adridg, jhale, rene, tcberner
Approved by: portmgr (implicit, flavor hook)
Differential Revision: https://reviews.freebsd.org/D17741
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
Replace bsd.qt.mk by Uses/qt.mk and Uses/qt-dist.mk
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: -https://reviews.freebsd.org/D15540
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
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
Get rid of QT_PREFIX in favour of PREFIX.
QT_PREFIX was a remnant of a bygone time.
Reviewed by: rakuco
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D8825
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), part II.
The first part covered 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.
This adds ports with USES=fortran and ports using Mk/bsd.octave.mk
which in turn has USES=fortran.
PR: 214965
Reported by: thierry
- Update to 4.10.2 [1]
- Add patches to fix build on head [1]
- Change MASTER_SITES to new directory structure [1]
- Take maintainership [1]
- Register proxy dependencies found by stage-qa for QT4 option
- Use options helpers
PR: 212186 [1]
Submitted by: Danilo G. Baio [1]
- Update to 4.10
- Update WWW
While here:
- Update LICENSE
- Convert non-functional (since February) USE_FORTRAN to USES=fortran
- Convert USE_PYTHON to USES=python:2 (3.x doesn't seem to work)
- Further convert to options helpers
- FORTRAN and QT4 options seem to build fine together, so make
them non-exclusive regular options
PR: 193590
Submitted by: pfg
- Update from 4.9 to 4.9.1
- Convert USE_GMAKE to USES
- Add stage support
- Convert LIB_DEPENDS to new syntax
while here:
- Convert some "if's" to options helpers
PR: ports/184838
Submitted by: KATO Tsuguru <tkato432@yahoo.com>
- Deprecate QT3, KDE3 and unmaintained ports depending on them. QT 3.3.8
was released in 2007 and KDE 3.5.10 in 2008 and both are no longer
maintained upstream nor in our tree.
- Set EXPIRATION_DATE to 2013-07-01
Discussed with: bapt, tabthorpe
- 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
-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
Convert most of remaining ports that depend on xorg-libraries to
modular xorg.
- supply corresponding USE_XORG for all imake-using ports that need it
- USE_IMAKE no longer implies USE_XLIB in absence of USE_XORG
- retire USE_X_PREFIX which is not really used anywhere after the
above change
- a few minor nits like whitespace and SF macro
Tested by: 2 tinderbox runs by pav
Approved by: portmgr (pav)
- Update to 4.6.2
- Hide the regression-test under a MAINTAINER_MODE since skipped checks appear
as failures
PR: 128447
Submitted by: "Pedro F. Giffuni" <giffunip at tutopia dot com> (maintainer)
- Cleanup the Makefile OPTIONS and correct some typos.
- This is in order to prepare for the update (which currently fails some
regression tests).
- No functional change.
PR: ports/127099
Submitted by: Pedro F. Giffuni <giffunip@tutopia.com> (maintainer)
science/silo add NO_LATEST_LINK
- This port is unrelated with x11/silo so I suppose
NO_LATEST_LINK is relevant.
- While here, remove the unnecessary $LOCALBASE includes
in CPPFLAGS/LDFLAGS for the configure environment.
PR: ports/126614
Submitted by: "Pedro F. Giffuni" <giffunip@tutopia.com>
- Turn off the python module as it causes breakage in the build cluster.
- While here, rename the BROWSER option to SILEXB to avoid confusion.
- No version bump since no package has been built.
PR: ports/125846
Submitted by: Pedro F. Giffuni <giffunip@tutopia.com> (maintainer)
Reported by: pointyhat via erwin
- New port silo-4.6.1
A mesh and field I/O library and scientific database
Silo is a library for reading and writing a wide variety of scientific
data to binary, disk files. The files Silo produces and the data within
them can be easily shared and exchanged between wholly independently
developed applications running on disparate computing platforms.
Consequently, Silo facilitates the development of general purpose tools
for processing scientific data. One of the more popular tools that process
Silo data files is the VisIt visualization tool.
Silo supports gridless (point) meshes, structured meshes, unstructured-zoo
and unstructured-arbitrary-polyhedral meshes, block structured AMR meshes,
(Only the first 15 lines of the commit message are shown above )
