this means getting rid of the Opm::filesystem namespace
and directly using std::filesystem, as well as dropping
some of the compat code for the tr filesystem.
we still need the FileSystem.hpp/cpp files though as unique_path
is not part of std::filesystem.
since we still support g++-7, where filesystem is marked experimental,
we introduce a wrapper header and expose the namespace to use
as Opm::filesystem.
for gcc we unconditionally link with libstdc++fs in the python bindings.
the setup.py stuff links as c code, not c++ code, so it is not
automatically added on any gcc version. this might prove unportable
later.
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.
Using an external cJSON installed under /usr/include was not possible before
as the cJSON headers within opm were still used due to relative paths.
With this commit move the copied cJSON source to external/cjson and
thus prevent them to be found if an externally installed cJSON is there.
This is an effort to improve build performance. Several includes
scattered across the project are either unused or partially used (i.e.
just used to import a type name, not depending on the actual contents of
the header file).
Replaces a lot of these includes with forward declarations.
- use a opm-macro to reduce code duplication
- add a 'test-suite' target which builds tests. for use if BUILD_TESTING
is 0.
- add a 'check' target which builds tests, then executes them
this is just the result of
```
find -iname "*.[ch]pp" | xargs sed -i "s/ *$//"
find opm/parser/share/keywords -type f | xargs sed -i "s/ *$//"
```
so if it causes conflicts with other patches, the others should get
priority. The rationale behind this patch is that some people tell
their editor to remove white space which leads to larger than
necessary patches...
i see no reason to keep the separate library and this circumvents
shared vs static linking issues.
an alternative fix is to fix the opm buildsystems to prioritize config
mode. that would be more involved.
- probe only for system lib (i.e. only probe in prefix paths)
old code ended up not installing the json lib due to finding a copy
in the build folder if a reconfiguration was performed.
- build internal copy static and bundle in libopm-json.so
no reason to install this as a shared library. if it is updated
originating from opm, the entire parser library is updated anyways.
these includes are required by the headers. If the affected files
would have been included without the headers included before, a
compiler error would have been produced.
