On Fri, Mar 11, 2011 at 9:41 AM, Jed Brown <jed at 59a2.org> wrote: > On Fri, Mar 11, 2011 at 13:02, Jose E. Roman <jroman at dsic.upv.es> wrote: > >> I have been adding support for cmake in SLEPc. My simple approach is: >> 1) generate a SLEPcConfig.cmake file >> 2) generate CMakeLists.txt with a cmakegen module adapted from petsc-dev >> 3) run cmake with a cmakeboot module adapted from petsc-dev >> >> Step 3 loads RDict and uses 'script' to process all PETSc configuration. >> The problem comes with prefix-based installations of PETSc, since 'script' >> is not available. >> > > Seems to me that necessary script support should be installed with prefix > installs too. I do not understand why "script" is such a cumbersome beast to > actually use, but it could be installed. However, exposing it to users turns > much of BuildSystem into a public API. This does not seem like a good idea, > especially with Barry's recent "cll" proposal for a much simpler alternative > to parts of BuildSystem. >
This does not help AT ALL. How is it bad? I use it all the time just fine, so I was not changing it unless there were complaints. Matt > > As a long-term solution, I think we should install a pkgconfig file and/or > a "petsc-config" script that knows about compilers, how to link shared > versus static, etc. > > >> Can anyone suggest a solution for this? Maybe use Jed's FindPETSc.cmake >> module? >> > > If you decide to use it, let me know if you find any problems. Writing > significant logic in cmake-script is no fun. > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/878ebc8d/attachment.html>
