On 23/06/14 09:06, Alf Birger Rustad wrote:
I think we all agree that OPM is (and in my opinions should remain)
more on libraries and core functionality, and less on end user
applications.
I hope we can cater to both, and today we really do. I believe
Resinsight and the upscaling codes are firmly positioned in the
end-user application category. For the reservoir simulation part it is
different, and I do believe you are right, we should design for making
it easy to use as libraries and core functionality. At the same time,
through the file format, we currently work hard at making an end-user
reservoir simulator. Actually, I believe the latter is necessary to
enable the former. That is, I am not sure we can rely on others
providing the end user application part.
To be honest I think I would have had to resort to Andreas suggestion
myself -- is this the time when I *really* should understand how
pkg-config works?
you don't have to use pkgconfig if you use cmake. all opm libraries
installs cmake config files. all you have to do is add a
'findpackage(xxx)' in your cmakelists, and you're off. no need for a
find rule, nothing.
pkg-config is only necessary for autotools users and/or when compiling
manually (nobody should do that..)
it's not hard to use.
g++ -c -o foo.o foo.cpp `pkg-config --cflags <dep>`
g++ -o foo foo.o `pkg-config --libs <dep>`
or, one shot usage for the tutorial;
g++ -std=c++11 -o test `pkg-config --cflags opm-core` tutorial1.cpp
`pkg-config --libs opm-core`
note that the opm tutorials are semi-broken. they unconditionally
include config.h, a file which does not exist for installations (nor
should it..)
arnem
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
