-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CMake branch] Does not configure on Ubuntu 10.04 LTS #122
Comments
I have not tried it on CMake less that 2.8.7. As much as I love my old Lucid, too, it becomes a question to which degree distributions which are close to expiry (on the deskop, at least) should be supported. enable_languages(Fortran) can of course be done, but this precludes building the package unless a Fortran toolchain is available (or we could make it optional, which is only half bad). Perhaps a better solution is to create a 'compatibility' directory which gets included if an older CMake is found, which has macros that "monkey-patch" the installation? |
I don't know how to resolve the issue, but I thought I'd mention that CentOS 5 (and 6, for that matter) come with CMake 2.6.4 rather than anything from the 2.8.x series. This may be an issue for those who use RHEL. On the other hand, building a more recent cmake binary is trivial so the impact might not be too heavy. |
On Tue, Jan 22, 2013 at 03:39:41AM -0800, Roland Kaufmann wrote:
You might want to take a look on how I solved this issue in DUNE: This used as follows: optional Fortran supportinclude(LanguageSupport) if(Fortran_Works) search for lapackfind_package(LAPACK) Write an empty FC headerfile(WRITE ${CMAKE_BINARY_DIR}/FC.h "") The downside of this is, that there will be no lapack/blas support if |
@blattms wrote:
At present the OPM-Core source code contains non-optional direct calls to BLAS and LAPACK subroutines. If I understand you correctly, this means that we will need a working, complete Fortran processing environment if we switch to using CMake. That's something to keep in mind. I am not about to relinquish a very mature code base for linear algebra. |
But, obviously, BLAS can be linked to without a working Fortran toolchain, so the problem is rather to have a better FindBLAS.cmake on older installations. My idea is to copy the needed files into a compat/ directory which gets included if the CMake version is too old. This will perhaps help us solve #113 also. |
@rolk stated:
That's not strictly true. It depends (a lot) on how the BLAS library was constructed. The official way of linking a C program that calls into the BLAS is to use something like $ gcc t.c $BLAS_LIBS $LIBS $FLIBS in which However, the fact that you can usually get by with simply $ gcc t.c $BLAS_LIBS $LIBS is usually a result of |
Please try if importing this commit to your cmake branch now enables you to build without modifications:
|
Using the change from the gist, I was able to get a lot further, but the process didn't complete. Now it hinges on the |
The irony here is that I think the macro was deprecated because they thought the name was confusing... Anyway, I don't expect the CMake boilerplate to make sense out of the YYYY.MM version scheme anyway, so a custom macro is in order. Which means that commit ae72485 and onward should be able to get you somewhat further; I think the best thing is to get a new checkout and then reapply the gist on top of that one; if we're able to actually get a configure through I'll commit it. |
More progress, but I still cannot get through configure (this time on my laptop, still Ubuntu 10.04 LTS, x86_64). I end up with lots of messages of the form
This is the ### installation ###
string (LENGTH ${PROJECT_SOURCE_DIR} _prefix_length)
foreach (_hdr IN LISTS opmcore_HEADERS)
get_filename_component (_dir ${_hdr} PATH)
string (SUBSTRING ${_dir} ${_prefix_length} -1 _rel_dir)
install (
FILES ${_hdr}
DESTINATION include${_rel_dir}
)
endforeach (_hdr) Is there something wrong on my end? |
I wrote:
The answer is: Yes, there is. My CMake is too old. Specifying |
I guess we could do
if that is supported... |
Yes, it (the Using that calculation I am able to run through the configuration without issue. Now, however, the build fails at the generation of the cd /tmp/opm/build/opm-core.git/dbg/lib && /usr/bin/objcopy --only-keep-debug "\$<TARGET_FILE:opmcore>" "\$<TARGET_FILE:opmcore>.debug"
/usr/bin/objcopy: '$<TARGET_FILE:opmcore>': No such file
make[3]: *** [lib/libopmcore.so.2013.2] Error 1
make[3]: Leaving directory `/tmp/opm/build/opm-core.git/dbg'
make[2]: *** [CMakeFiles/opmcore.dir/all] Error 2
make[2]: Leaving directory `/tmp/opm/build/opm-core.git/dbg'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/opm/build/opm-core.git/dbg'
make: *** [__everything] Error 2 This is a configuration that was set up using the command $ cmake ../../../opm-core/ -DCMAKE_INSTALL_PREFIX=/home/bska/usr/local -DCMAKE_BUILD_TYPE=Debug as advised in the CMake branch |
No, but the $<TARGET_FILE:...> construct is probably only supported in a newer CMake version (2.8.4), and interpreted literally in the old version (someone should point out to KitWare the meaning of patch version numbers!) |
I feel your pain. To be honest, there is some precedence to changing things in (very) minor version number. For instance, GNU Make made an incompatible change (I forget which) to the language between versions 3.80 and 3.81... |
New attempt to work around this with cmake branch up to commit bf7f89a. (this include the previous mentioned gist too, so you can just checkout anew if you have none of your own changes (little likely, since it doesn't build)) |
I forgot to follow up on this issue. The cmake branch as of commit 8a732c1 works perfectly on Ubuntu 10.04 LTS. I did experience something slightly worrying, simply issuing In any case, this issue is solved as far as I am concerned. I'll close it. |
This is on the CMake branch, currently being evaluated for inclusion into mainline OPM-Core (cf. issue #119). I am unable to perform even basic configuration on my current work station which runs Ubuntu 10.04 LTS (x86_64).
FindBLAS.cmake
macro that comes with CMake 2.8.0 (package version on Ubuntu 10.04) requires Fortran. I had toenable_languages (Fortran)
in theCMakeLists.txt
file.FindSUPERLU.cmake
implementation in uses thecmake_push_check_state()
macro (on line 69 as of commit 1a94211). As far as I can tell, thecmake_push_check_state()
macro was not introduced until CMake 2.8.6. What is the minimum version of CMake required to configure the project?The text was updated successfully, but these errors were encountered: