Commit Graph

5 Commits

Author SHA1 Message Date
Bård Skaflestad
c013639b51 Make Most Unit Tests Independent of LibECL
This commit switches a set of OPM-Common's unit tests away from
using direct calls to libecl functions and into using base types
from OPM-Common itself (along with Boost.Filesystem).

In particular summary related queries are replaced by calls to ESmry
member functions (wrapped in libecl-like interfaces to minimise code
changes).  We disable checks on unit strings since ESmry currently
does not have a way of associating those with individual variables.
2019-10-14 06:13:38 -05:00
Bård Skaflestad
ffecc035c0 InitConfig: Internalize FILLEPS Keyword
This commit extends the InitConfig class to support querying whether
or not the FILLEPS keyword is present in the PROPS section.  Note
that we only look for the keyword in PROPS (not the whole input
deck), since the keyword is only permitted in PROPS.

Add unit tests to exercise the new ability.
2019-06-24 14:15:55 +02:00
Joakim Hove
2cd6fa2f49 Add overloads without ParseContext and ErrorGuard - update all tests 2019-01-04 13:59:28 +01:00
Joakim Hove
4502333751 Ensure that path to restart file is interpreted relative to DATAFILE 2018-07-20 22:11:12 +02:00
Jørgen Kvalsvik
e884b0664c Redesign cmake
Tune the makefile according to new principles, which adds a few bells
and whistles and for clarity.

Synopsis:

* The dependency on opm-common is completely gone. This is reflected in
  travis and appveyor as well. No non-kitware cmake modules are used.
* Directories are flattened, quite a bit - source code is located in the
  lib/ directory if it belongs to opm-parser, and external/ if third
  party.
* The sibling build feature is implemented through cmake's
  export(PACKAGE) rather than implicitly looking through source files.
* Targets explicitly set required public and private include
  directories, compile options and definitions, which cmake will handle
  and propagate
* opm-parser-config.cmake for downstream users is now provided.
* Dependencies are set up using targets. In the future, when cmake 3.x+
  can be used, these should be either targets from newer Find modules,
  or interface libraries.
* Fewer system specific assumptions are coded in, instead we assume
  cmake or users set up system specific details.
* All module wide configuration and looking up libraries is handled in
  the root makefile - all sub directories only set up libraries and
  compile options for the module in question.
* Targets are defined and links handled transitively because cmake now
  is told about them. ${module_LIBRARIES} variables are gone.

This is largely guided by the principles outlined in
https://rix0r.nl/blog/2015/08/13/cmake-guide/

Most source files are just moved - if they have some content change then
it's nothing more than include fixes or similar in order to make them
compile.
2017-06-01 15:29:23 +02:00