On 2014-06-26 14:55, Arne Morten Kvarving wrote:
if an application uses config.h unconditionally, that is a
bug.
On 2014-06-27 00:14, Andreas Lauser wrote:
all source files of the libraries are compiled with taking the
macros of config.h in consideration. If you now try to compile
with another set of values for these macros, you will get
unexpected behavior
This means that config.h is always required and that it needs to
be compatible with the one used to compile the libraries...
On 2014-06-27 09:11:28 Paolo Orsini wrote:
If this is the case, wouldn't it make sense to copy the config.h
to the system include folder during the installation?
On 2014-06-27 10:20, Andreas Lauser wrote:
What it boils down to is that in the end external projects either
need to either use the same build system as OPM or put a lot of
effort into making its own one compatible.
I concur with Arne Morten: It should be regarded as a bug that config.h
is included in public files (because it put constraints on your build
system), and config.h from the build machine should never be included in
the distribution (because it does not apply to the target).
What is important is as Andreas says that your machine is configured in
a way that is compatible with the library. Packages which are irrelevant
for OPM can of course be different. config.h is a synopsis of the
packages installed on your machine, as detected by that particular build
system. Which means that there can be other things in there which are
relevant for your project, but not for OPM.
You do not have to use the OPM build system to use the OPM libraries,
but you have to make sure that you build your program with some of the
same options (e.g. if OPM was build with -std=c++11, you must do that too).
The OPM build system generates a bunch of files to help you with that:
pkg-config files, M4 files for Autotools and files for CMake projects.
--
Roland.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
