dolfin team mailing list archive

[Kent-Andre Mardal <kent-and@xxxxxxxxx>]

On 21 January 2013 09:02, Johan Hake <hake.dev@xxxxxxxxx> wrote:

> On 01/20/2013 07:33 PM, Kent-Andre Mardal wrote:
> >
> >
> > On 19 January 2013 23:48, Johan Hake <hake.dev@xxxxxxxxx
> > <mailto:hake.dev@xxxxxxxxx>> wrote:
> >
> >     On 01/19/2013 10:46 PM, Garth N. Wells wrote:
> >     > I've got all of DOLFIN and the unit tests working nicely with OSX
> 10.8
> >     > / Macports / clang, except the JIT unit test
> >     >
> >     >     test_compile_extension_module
> >     >
> >     > I have no idea how to debug it. The seg fault is triggered by the
> line
> >     >
> >     >     VecExp(*x);
> >     >
> >     > My best guess is that the pkg-config linking is bad. Any other
> ideas
> >     > or suggestions on how to fix it?
> >
> >     Do you have several libpetsc installed?
> >
> >     > Can we finally get rid of the pkg-config garbage and use CMake for
> the
> >     > jit linking?
> >
> >     It might be a combination of pkg-config and distutils. In the latter
> >     library_dirs and libraries are two different arguments to the
> Extension
> >     class. This means that we split the library dirs and libraries from
> each
> >     other destroying all information about library_dir to library order.
> >     This is actually preserved in the pkg-config file.
> >
> >     If we are going to shift to CMake we need not only ditch pkg-config,
> but
> >     also distutils. Kent has added support for CMake compilation for VTK
> and
> >     ITK based modules, which more easily is find using find_package
> calls.
> >
> >     I can have a look at this next week. I think using CMake instead of
> >     distutils also opens up for easier compiler configurations, as this
> can
> >     be quite obscure in distutils.
> >
> >
> >
> > I agree that it is time to use cmake instead of pkg-config.
> >
> > Dolfin needs to provide a Dolfin.cmake file. The rest is simple, from
> > Instant's point of view.
>
> I agree that getting this up and running should in principle be simple.
> But there are some hurdles.
>
> How do we keep all functionality we have in build_module, with disk
> caching, file locking, error handling, while switching to CMake? And how
> do we keep backward compatibility? Have in mind that several other
> applications use instant.
>
> Johan
>

Agree that this functionality should be kept.
I can have a look at it. However, first
Dolfin need to provide FindDolfin.cmake and UseDolfin.cmake files.
Johannes, I guess you have made several such files before. Can you look at
it?

Kent