On 01/21/2013 12:58 PM, Garth N. Wells wrote: > On 21 January 2013 11:43, Kent-Andre Mardal <[email protected]> wrote: >> >> >> On 21 January 2013 09:02, Johan Hake <[email protected]> wrote: >>> >>> On 01/20/2013 07:33 PM, Kent-Andre Mardal wrote: >>>> >>>> >>>> On 19 January 2013 23:48, Johan Hake <[email protected] >>>> <mailto:[email protected]>> 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 >> _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
