dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 21 January 2013 11:43, Kent-Andre Mardal <kent-and@xxxxxxxxx> wrote:
>
>
> 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.

DOLFIN shouldn't provide FindDolfin.cmake. That's the task of CMake or
the application developer, if is necessary, which it usually isn't if
the library produces a CMake config file. DOLFIN provides

    dolfin-config.cmake

A small number of projects provide UseDolfin.cmake. What's it used for
beyond the regular dolfin-config.cmake file?

Garth

> Johannes, I guess you have made several such files before. Can you look at
> it?
>
> Kent
>