8000 Tags · blattms/opm-material · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Tags: blattms/opm-material

Tags

release/2015.04/final

Toggle release/2015.04/final's commit message
update redhat packaging

release/2015.04/rc3

Toggle release/2015.04/rc3's commit message
Update Eigen requirements.

Manually imported from opm-autodiff.

release/2015.04/rc1

Toggle release/2015.04/rc1's commit message
Update Eigen requirements.

Manually imported from opm-autodiff.

release-2015.04-branchpoint

Toggle release-2015.04-branchpoint's commit message
change the version number to the scheme used by eWoms

i.e., there is no distinction between the "API version" and the
"Release version" anymore. IMO, the split scheme is just confusing for
no benefit because we are handling API/ABI changes in a pretty relaxed
manner anyway: i.e., whenever the "release version" gets incremented,
the "API version" needs to follow suite!

release/2013.10/final

Toggle release/2013.10/final's commit message
Tag final for 2013.10 release of OPM

release/2013.10/rc3

Toggle release/2013.10/rc3's commit message
Install header-only pkgconfig file to generic lib/

The previous version assumed that we had libraries, and thus always
installs the .pc file in the multi-arch library directory. However,
we now have modules which does not have a library, but whose header
files still need to be located. Since the lib/ directory is usually
in the pkgconfig search path, it is natural to put them there.

release/2013.10/rc2

Toggle release/2013.10/rc2's commit message
Install header-only pkgconfig file to generic lib/

The previous version assumed that we had libraries, and thus always
installs the .pc file in the multi-arch library directory. However,
we now have modules which does not have a library, but whose header
files still need to be located. Since the lib/ directory is usually
in the pkgconfig search path, it is natural to put them there.

release/2013.10/rc1

Toggle release/2013.10/rc1's commit message
Allow static linking for SuiteSparse to be forced

If -DSUITESPARSE_USE_STATIC=ON, then the build system will only look for
static versions of the libraries that are part of SuiteSparse, even if
dynamic/shared versions are present on the system. Thus, the default of
preferring dynamic libraries can be overridden.

SuiteSparse is rarely built ourselves, but still uncommon enough to not
be present on computing clusters.

This patch allows us to install the libraries on a workstation, for
instance from package suitesparse-devel and link to it statically
without having to maintain our own build tree.
0