- removed comment
Build fails if Fortran is not available
If you use the old generic.cfg (which has "none" for both F77 and F90) and a thornlist that consists of the flesh only, Cactus will not compile. It will complain that CCTK_REAL is undefined.
Interestingly, if no definition is provided for F77 and F90 in the optionlist, then the Cactus build system assumes gfortran and compiles.
If, however, in addition to not defining F77 and F90 in the cfg, no fortran is actually present (i.e. not installed), then the CCTK_REAL issue returns.
Keyword:
Comments (19)
-
-
- changed status to open
- removed comment
-
- changed status to open
- removed comment
Thank you for the patch.
This seems like an odd way to handle this. The Kranc tutorial http://kranccode.org/tutorial.html seems to suggest that at least at the time of writing that tutorial a C / C++ compiler (no Fortran) was sufficient.
Rather than having the AC test for
CCTK_REAL
run with the "no-fortran-compiler" executable and then after the fact realize what was done I would rather suggest to not run the AC test at all.I am not sure if there is anyone still involved in Cactus who might know, but what is the reason for the existence of no-fortran-compiler ?
I will try and see if I can find an ET release that lets me compile at least an empty thornlist with only a C and C++ compiler but no F77 or F90 compiler present (by removing gfortran from my PATH).
-
- removed comment
The reason for not requiring Fortran is that some systems do not have a Fortran compiler, and since all of the flesh and basic thorns are (were) written in C, requiring a Fortran compiler was an unnecessary requirement that would prevent people from using Cactus.
At that time, there were many different operating systems (not just Linux, Windows, and MacOS), and may different C compilers. GCC was not necessary available on a Unix system. There was also no free Fortran 90 compiler in existence. Hence installing a Fortran compiler was a real obstacle, in particular annoying if one didn't have any Fortran code. Consequencly, using Cactus without Fortran was working out of the box, unless one used Fortran thorns.
-
reporter - removed comment
This has been broken for a very long time, probably since 2010 at least. I encountered the problem at the very first Cactus tutorial I was in charge of. I should have made a ticket right then.
-
- removed comment
The Kranc tutorial definitely did not require a Fortran compiler. I can confirm that it no longer works. I get
COMPILING arrangements/CactusBase/Boundary/src/ScalarBoundary.c In file included from /home/ian/Cactus/configs/kranc/bindings/include/Boundary/cctk_Arguments.h:14:0, from /home/ian/Cactus/configs/kranc/bindings/include/Boundary/cctk_ScheduleFunctions.h:1, from /home/ian/Cactus/configs/kranc/bindings/include/Boundary/cctk.h:6, from /home/ian/Cactus/configs/kranc/build/Boundary/ScalarBoundary.c:19: /home/ian/Cactus/src/include/cctk_Types.h:176:21: error: unknown type name 'CCTK_REAL8' # define CCTK_REAL CCTK_REAL8 ^ /home/ian/Cactus/src/include/cGH.h:41:3: note: in expansion of macro 'CCTK_REAL' CCTK_REAL cctk_delta_time;
The Kranc tutorial has a Jenkins job to automatically test it. However, since the Jenkins system moved to NCSA, there is no longer any mathematica licence available, so we cannot run the tutorial there.
Do we understand why CCTK_REAL is not defined? Is this really linked to the absence of a Fortran compiler? Note that the Kranc tutorial doesn't use any optionlist at all. Cactus should automatically find everything it needs.
-
- removed comment
I ran this test
cd repos/flesh for i in `git branch -a | gawk -vFS=/ '/remotes\/origin\/ET_/{print $NF}'` ; do git checkout $i cd ../.. rm -rf configs/null/ F90=none F77=none make null-config THORNLIST=/dev/null PROMPT=no || bash cd - done
which finds the first failure in the ET_2014_05 release. So something changed in the flesh in between that makes it fail if there is no F90 or F77 compiler.
I think it would be better to fix that regression than to add a workaround right now.
-
- removed comment
I ran git bisect to find the responsible commit. It claims it is this one: https://bitbucket.org/cactuscode/cactus/commits/e8f2db41cd59986b256d282c57557daed035d4b6
commit e8f2db41cd59986b256d282c57557daed035d4b6 Author: Erik Schnetter <schnetter@cct.lsu.edu> Date: Sat Apr 19 11:01:12 2014 +0000 Drop explicit support for Fortran 77 in Cactus This patch drops explicit support for Fortran 77 in Cactus. Fortran 77 is, for all practical purposes, a subset of Fortran 90, and thus Fortran 77 code can be compiled by Fortran 90 compilers. There is currently no platform that has a Fortran 77 and no Fortran 90 compiler, and there is no Fortran source code in Cactus that cannot be compiled by a Fortran 90 compiler. This patch removes/ignores all configuration options regarding Fortran 77, and compiles .f77 and .F77 files with a Fortran 90 compiler. This simplifies the configuration stage of Cactus.
-
- removed comment
For reference, git bisect was run like this:
cd repos/flesh cat >test_cctk_real <<EOF #!/bin/bash cd ../.. rm -rf configs/null rm -f repos/flesh/log.txt F90=none F77=none make null-config THORNLIST=/dev/null PROMPT=no >repos/flesh/log.txt 2>&1 EOF chmod u+x test_cctk_real git bisect start 4c1114c004274bc13ea97a917ca0223259117018 e1ab21232c9a093812275bc08ba74870b28a0f45 -- git bisect run ./test_cctk_real
Note that the two hashes are the "bad" and "good" commits respectively. In each case, I took the commit on the master branch which was branched from to make the release branches, otherwise git bisect complains that there is no merge base being tested because one commit is not an ancestor of the other.
-
- removed comment
Given the commit message, it looks like this was the commit which implemented
#1725(Disable Fortran 77 support in Cactus). That ticket contained a proposal to remove the support, and was placed in the review state, but there was no code to review. It looks like the code was committed anyway in https://bitbucket.org/cactuscode/cactus/commits/e8f2db41cd59986b256d282c57557daed035d4b6, without having been reviewed (not that I'm claiming a review would have seen the problem, but it would have made it a bit more likely...). -
- removed comment
Turns out the original code https://bitbucket.org/cactuscode/cactus/commits/e8f2db41cd59986b256d282c57557daed035d4b6#Llib/make/configure.inF1155 did almost exactly what Frank is re-introducing using "none" for the magic F77 / F90 value. Not sure if / when no-fortran-compiler was introduced.
-
- changed title to Build fails if Fortran is not available
- removed comment
-
- removed comment
I think I may have reviewed the commit actually (or at least remember it being proposed), though I quite likely missed the check for "none" since everything else is pretty trivial changes.
-
- changed status to open
- removed comment
-
- changed status to open
- removed comment
no-fortran-compiler was introduced in
commit c44dd46973226cb319bd9f8bd5d769164cc42ee2 Author: Erik Schnetter <schnetter@gmail.com> Date: Tue Apr 26 07:37:08 2016 -0400 Cactus: Simplify handling a missing Fortran compiler at build time
and Frank's patch seems to do exactly what used to be done in the past. I will reword the commit message to state this and amend a "Cactus:" in front of it if this alright with everyone (author will remain Frank).
-
- removed comment
I confirm that I can no longer reproduce the bug on this branch. I have not reviewed the commit, but since Roland and Frank have both had eyes on it, it's probably fine to commit, unless someone else objects. Erik?
-
reporter - removed comment
I can also confirm that this patch works.
-
- changed status to resolved
- removed comment
Well I'll just commit even without Erik's go ahead.
Pushed as git commit 10fe176b "Cactus: be more careful about =~ vs ne in perl scripts" of the flesh.
-
- edited description
- changed status to closed
- Log in to comment
See https://bitbucket.org/cactuscode/cactus/pull-requests/43/define-cctk_real-if-no-fortran-compiler-is