dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday August 10 2010 02:06:54 Anders Logg wrote:
> On Tue, Aug 10, 2010 at 09:50:36AM +0100, Garth N. Wells wrote:
> > On Tue, 2010-08-10 at 10:48 +0200, Anders Logg wrote:
> > > On Tue, Aug 10, 2010 at 09:46:03AM +0100, Garth N. Wells wrote:
> > > > On Tue, 2010-08-10 at 10:32 +0200, Anders Logg wrote:
> > > > > On Tue, Aug 10, 2010 at 09:26:06AM +0100, Garth N. Wells wrote:
> > > > > > On Tue, 2010-08-10 at 09:47 +0200, Anders Logg wrote:
> > > > > > > Maybe a .cmake file will be useful, but I think the first
> > > > > > > option should be to (1) generate a pkg-config file and (2) use
> > > > > > > simple Makefiles for all the demos.
> > > > > > 
> > > > > > A .cmake file is probably a bit more than just useful if we want
> > > > > > to take advantage of the cross-platform features of CMake.

> > > > > ok.
> > > > > 
> > > > > > An awkwardness with pkg-config + CMake is that we need a
> > > > > > FindFoo.cmake file for each dependency, then we also need to
> > > > > > create a pkg-config for each dependency, both of which do more
> > > > > > or less the same thing. We created pkg-config files with SCons,
> > > > > > so hopefully this is just as easy with CMake.

It looks like CMake can use pkg-config files, so then we just need to figure 
out how to generate them with CMake...

> > > > > Do we really need to create pkg-config files for all dependencies?
> > > > > It should be enough for us to provide the flags for how to build
> > > > > against DOLFIN (which in turn is linked against its
> > > > > dependendices).
> > > > 
> > > > It would work, but is not very elegant. It wouldn't be possible to
> > > > pick and use which version of a library to use (not that we do that
> > > > now ;)).

Do you want a cmake-gui to handle directory choice for all DOLFIN 
dependencies, when compiling your applications?

Johan

> > > > 
> > > > Garth
> > > 
> > > Isn't that decided at compile time (for DOLFIN)? If we build DOLFIN
> > > against a certain version of PETSc, I imagine it would break hard if
> > > someone tried to later change that to another PETSc version.
> > 
> > I would expect it to work if I switched between say debug and optimised
> > versions of PETSc, or if I decided to move a library from one location
> > to another.
> 
> ok. I've never done that but perhaps it's a feature we need.
> 
> --
> Anders