dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 01/21/2013 12:58 PM, Garth N. Wells wrote:
> 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?

No need for FindDolfin.cmake The only thing we need to do in the
generated CMakeLists.txt file is to call:

  find_package(dolfin)

The CMakeFile from a cpp demo can be used as a prototype.

Johan


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