Closed BarrySmith closed 4 years ago
bartlettroscoe
commented
8 years ago @BarrySmith, it looks like perhaps STDERR and STDOUT are not geting output in order correctly in the above cmake output. How did you produce this ouptut file? What I usually do on bash is:
$ cmake [options] &> configure.outand that gets things in the right order in configure.out.
bartlettroscoe
commented
8 years ago @curfman,
Yea, it is my understanding that Macs don't come with a Fortran compler installed by default (and Clang are the default C and C++ compilers). I might recommend for your demo that you use NoMachine (NX) and access a Linux machine from your Mac laptop for your live demo. A Linux env will be much faster and easier to set up. (If you have not used NX before, then you will be in for a real treat once you get it set up.)
Most of Trilinos (but not all packages) should build just fine without Fortran. But I don't think you can build SEACAS without Fortran, and perhaps a few other packages.
To build Trilinos without Fortran, you need to configure with -DTrilinos_ENABLE_Fortran=OFF (and for xSDKTrilinos, it will be -DxSDKTrilinos_ENABLE_Fortran=OFF). However, I don't think that there are any "Fortran-free" automated builds of Trilinos are currently running from looking at:
http://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2016-05-19&showfilters=1
@jwillenbring and @bmpersc, do you know if there are any Fortran-free automated builds of Trilinos running? What happens when you disable Fortran build enable SEACAS?
Therefore, I don't know what Trilinos packages will work with Fortran disabled. But I know that some people at Sandia have been using a Fortran free build of Trilinos in order to be able to use Ninja (instead of Makefiles).
Also, I think there is still a dynamic library issue on Mac (see #91) that I don't think that anyone has addressed yet. I inquired about this on March 16 (see here) but never got a reply. I think fixing that might be a couple line change in TriBITS. But since I don't have access to a Mac, I can't reproduce or test these builds. It would be great if someone with a Mac on the Trilinos could help out with these things.
From: McInnes, Lois Curfman [mailto:curfman@mcs.anl.gov] Sent: Friday, May 20, 2016 7:36 AM To: Willenbring, James M; Heroux, Michael A; Bartlett, Roscoe A Cc: Smith, Barry F. Subject: [EXTERNAL] FW: [trilinos/Trilinos] trilinos without fortran compiler? (#375)
Hi Jim, Ross, Mike:
Just a note to say that this issue came up when I was using xSDKinstall on my laptop (for the first time); Barry is assisting. I do not currently have a fortran compiler installed. Apparently this is the first time that installxSDK was tested without a fortran compiler being specified. This was a problem also for SuperLU (reported to Sherry).
Because the program managers have emphasized repeatedly that they want to be able to see xSDK code/demos ‘live’ in addition to the movie/demo clips that we are making, I am trying to get my laptop set up to have the xSDK ready to show as needed at the review on June 2.
So, it would be good to know how you recommend that I proceed. If the answer is: get a fortran compiler … then I will do that and move on to the next step ...
Thanks, Lois
bartlettroscoe
commented
8 years ago But note that you are not going to be able to build PFLOTRAN and Alquimia without Fortran. Therefore, I would say you need Fortran if you are going to build the xSDK.
In the document "xSDK Standard GNU Autoconf and CMake Options", it says "The default is to have C and C++ enabled and Fortran disabled. Packages that do not use Fortran (or C++) are free to ignore that flag." It appears that we did not actually implement that. While Trilinos can build most of its packages without Fortran, is that good enough for an xSDK install?
How do we resolve this?
gsjaardema
commented
8 years ago There are portions of SEACAS that can be built without a Fortran compiler. I've tried building just SEACAS with Fortran disabled and I am getting similar errors as shown above. The most telling seems to be the
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_Fortran_LINK_EXECUTABLE
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.which happens many times. Then, when I try to build, I get the following error:
[ 62%] Linking C static library libexodus.a
Error running link command: No such file or directoryNote that libexodus.a is a C library, so should build correctly with no FORTRAN compiler. If I do make VERBOSE=1, then I see that the archiver seems to be missing:
[ 62%] Linking C static library libexodus.a
cd /Users/gdsjaar/src/seacas/build/packages/seacas/libraries/exodus && /opt/local/bin/cmake -P CMakeFiles/exodus_static.dir/cmake_clean_target.cmake
cd /Users/gdsjaar/src/seacas/build/packages/seacas/libraries/exodus && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/exodus_static.dir/link.txt --verbose=1
"" qc libexodus.a CMakeFiles/exodus_static.dir/src/ex_add_attr.c.o CMakeFiles/exodus_static.dir/src/ex_close.c.o CMakeFiles/exodus_static.dir/src/ex_conv.c.o CMakeFil...The double quotes right before the qc libexodus.a are /opt/local/bin/ar on a build with Fortran enabled:
[ 34%] Linking C static library libexodus.a
cd /Users/gdsjaar/src/seacas-parallel/build/packages/seacas/libraries/exodus && /opt/local/bin/cmake -P CMakeFiles/exodus_static.dir/cmake_clean_target.cmake
cd /Users/gdsjaar/src/seacas-parallel/build/packages/seacas/libraries/exodus && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/exodus_static.dir/link.txt --verbose=1
/opt/local/bin/ar qc libexodus.a CMakeFiles/exodus_static.dir/src/ex_add_attr.c.o CMakeFiles/exodus_static.dir/src/ex_close.c.o CMakeFiles/exodus_static.dir/src/ex_conv.c.o ...This seems to work correctly for shared libraries but is failing for the archive step of the static libraries. Not sure where the problem lies...; maybe this will help track things down...
jwillenbring
commented
8 years ago The no fortran build we had was on a Mac, and that machine went down. I don't think there is anything currently. We should have one though, you are right.
bartlettroscoe
commented
8 years ago The no fortran build we had was on a Mac, and that machine went down. I don't think there is anything currently. We should have one though, you are right.
This is one of the big problems we have with Trilinos testing. We have important automated tests that are set up on only one machine and then we that machine is taken out, we loose those tests and there is no effort to transition those tests to another machine. For example, there used to be really good automated performance tests for Teuchos that ran every night on brain but when that machine was retired, those tests never got moved over to another machine.
We need to have a rule in Trilinos which is that before a testing machine is retired, we list out important unique builds on that machine that need to be migrated to a new machine and then create Issue tickets for that in the SEMS backlog with high priority to complete. Otherwise, it is always one step forward, two steps back with automated Trilinos testing.
bartlettroscoe
commented
8 years ago There are portions of SEACAS that can be built without a Fortran compiler. I've tried building just SEACAS with Fortran disabled and I am getting similar errors as shown above.
@gsjaardema, if there are SEACAS subpackages that require Fortran to build correctly, you can put in disables when Fortran is not enabled. You can see how this is being done for other packages like ForTrilinos in the file Trilinos/cmake/CallbackSetupExtraOptions.cmake. For example:
IF (NOT ${PROJECT_NAME}_ENABLE_Fortran)
MESSAGE(
"\n***"
"\n*** Warning: Setting ${PROJECT_NAME}_ENABLE_ForTrilinos=OFF"
" because ${PROJECT_NAME}_ENABLE_Fortran=OFF!"
"\n***\n"
)
SET(${PROJECT_NAME}_ENABLE_ForTrilinos OFF)
ENDIF()This should likely be changed to:
IF (NOT ${PROJECT_NAME}_ENABLE_Fortran)
IF (${PROJECT_NAME}_ENABLE_ForTrilinos)
MESSAGE("-- "
"WARNING: Setting ${PROJECT_NAME}_ENABLE_ForTrilinos=OFF"
" even though it was set to ${${PROJECT_NAME}_ENABLE_ForTrilinos}"
" because ${PROJECT_NAME}_ENABLE_Fortran=OFF!"
)
ELSEIF("${${PROJECT_NAME}_ENABLE_ForTrilinos}" STREQUAL "")
MESSAGE("-- "
"NOTE: Setting ${PROJECT_NAME}_ENABLE_ForTrilinos=OFF"
" because ${PROJECT_NAME}_ENABLE_Fortran=OFF!"
)
ENDIF()
SET(${PROJECT_NAME}_ENABLE_ForTrilinos OFF)
ENDIF()We can break this logic out as a macro and then reuse it for SEACAS subpackages that require Fortran.
In my opinion, disables should trump enables (but print warnings). But as you can see for that file, this was not the decision for packages requiring C++11.
Does that sound reasonable? If so, just let me know what SEACAS subpackages require Fortran and then I can do this part. But note this commit needs to be done on the 12.6 release branch then merged to the 'master' branch. I can also take care of that.
gsjaardema
commented
8 years ago I can do that. However, I'm not sure how the release-branch-to-master workflow works/applies to seacas. The current workflow is that I make the changes in Sierra/SEACAS-standalone and then Brent syncs them over to Trilinos. I would think that making changes to 12.6 and then merging to master will break the current process (which is known to be broken/non-optimal).
Won't this process also be broken if SEACAS goes to the "kokkos" model in which I snapshot SEACAS changes into Trilinos? Maybe the "snapshotted" repositories need to mirror the branches that are in the Trilinos repository?
Brent should probably comment... @bmpersc
bartlettroscoe
commented
8 years ago I can do that. However, I'm not sure how the release-branch-to-master workflow works/applies to seacas. The current workflow is that I make the changes in Sierra/SEACAS-standalone and then Brent syncs them over to Trilinos. I would think that making changes to 12.6 and then merging to master will break the current process (which is known to be broken/non-optimal).
Won't this process also be broken if SEACAS goes to the "kokkos" model in which I snapshot SEACAS changes into Trilinos? Maybe the "snapshotted" repositories need to mirror the branches that are in the Trilinos repository?
If you revert the commit in the snapshot repo and then do the sync, it will be fine. See how this is done for TriBITS at:
http://trac.trilinos.org/wiki/TriBITSTrilinosDev#trilinos_tribits_changes
There is more that I need to explain about this process but it is very effective and will never create any merge conflicts. I have a backlog story to explain this workflow along with other multi-repo workflows as part of the IDEAS Productivity project. It appears that that story is getting more and more urgent.
gsjaardema
commented
8 years ago SEACAS Libraries requiring fortran:
SEACAS Applications requiring fortran:
gsjaardema
commented
8 years ago Note that all of the applications requiring fortran also require the exodus_for, supes, and suplib libraries, so perhaps just disabling the libraries will automatically propagate the disables to the applications...
The suplib library contains some C files which are used by some C/C++ applications, so I should probably split that library into a suplib_for and suplib_c similar to what was done earlier with suplib_cpp.
bartlettroscoe
commented
8 years ago Okay, looks like those directly map to SEACAS subpackages listed in Trilinos/packages/seacas/cmake/Dependencies.cmake. Wow, that is 21 subpackages in SEACAS that require Fortran. By my count of the subpackages listed in that file, that only leaves 18 out of 39 total SEACAS subpackages. How useful are those remaining 18 subpackages?
Okay, so that this point we should likely create a new Issue for disabling subpackages in SEACAS when Fortran is not enabled and then block this Issue with that issue.
gsjaardema
commented
8 years ago The remaining are very useful.
mhoemmen
commented
8 years ago @bartlettroscoe @BarrySmith As a temporary work-around, why not just disable SEACAS if Fortran is not enabled? Do any xSDK applications need it?
bartlettroscoe
commented
8 years ago Note that all of the applications requiring fortran also require the exodus_for, supes, and suplib libraries, so perhaps just disabling the libraries will automatically propagate the disables to the applications.
Right, it would be simpler to just disable the library subpackages and then verify that they correctly take out the downstream app subpackages.
The suplib library contains some C files which are used by some C/C++ applications, so I should probably split that library into a suplib_for and suplib_c similar to what was done earlier with suplib_cpp.
Remember that we need to make this change on the Trilinos 12.6 release branch so that it will positively impact the IDEAS xSDK release. But that is no problem with git format-patch and git am workflow if you apply it carefully. I can give @bmpersc the exact git commands to run before his next sync of SEACAS to avoid any merge conflicts.
gsjaardema
commented
8 years ago Probably the only one that would be needed is exodus and it looks like that is being explicitly disabled. If any are needed, it would be easiest to just explicitly enable those.
rppawlo
commented
8 years ago It is very useful. Panzer and Drekar require multiple SEACAS libraries and applications and we can build and run all Drekar tests with fortran disabled.
bartlettroscoe
commented
8 years ago As a temporary work-around, why not just disable SEACAS if Fortran is not enabled? Do any xSDK applications need it?
That is a great question. Does xSDK or the IDEAS app teams (i.e. Amanzi) need SEACAS out of Trilinos? Who would know the answer to that.
gsjaardema
commented
8 years ago Wouldn't it be easier to fix the fortran issue? I think the disable SEACAS comment was just for the demo; not for xSDK in general.
jwillenbring
commented
8 years ago Would it be bad to just commit to the release branch, then have the change applied to the SEACAS repo, then eventually bring it back to Master through the usual process? If someone does merge back, that commit should just be skipped, like a release-only commit. I know that isn't a merge back to Master, but it seems reasonable to me.
bartlettroscoe
commented
8 years ago Would it be bad to just commit to the release branch, then have the change applied to the SEACAS repo, then eventually bring it back to Master through the usual process? If someone does merge back, that commit should just be skipped, like a release-only commit. I know that isn't a merge back to Master, but it seems reasonable to me.
The changes to Trilinos/packages/seacas/cmake/Dependencies.cmake which would disable the Fortran subpackages for SEACAS would not impact the Trilinos/packages/seacas/ snapshot at all. Therefore, as long as we don't bother breaking out C files from the SEACAS suplib subpackage in the release branch, then the merge from the release branch to 'master' will not impact the SEACAS updating that Brent does at all. Right?
That way, we don't break the release branch merge workflow for Trilinos (or require any extra work in the merge back to 'master').
bartlettroscoe
commented
8 years ago Wouldn't it be easier to fix the fortran issue?
@gdsjaar, how would you "fix" the Fortran issue in SEACAS? For Trilinos, it was a lot of work to make a Fortran-free build. We had to run f2c on several Fortran subroutines and build those when Fortran was disable.
gsjaardema
commented
8 years ago @gdsjaar, how would you "fix" the Fortran issue in SEACAS?
Instead of disabling ALL of SEACAS in xSDK, adding the subpackage disables which we had been discussing prior to the comment about disabling all of SEACAS.
agsalin
commented
8 years ago Echoing what Roger said: the non-fortran SEACAS packages such as exodus and loss are the ones we heavily use in Albany.
jwillenbring
commented
8 years ago Amanzi uses SEACAS. I am not sure which parts of it. So the xSDK does need SEACAS.
rppawlo
commented
8 years ago We use these packages with fortran disabled: Panzer requires: SEACASIoss SEACASExodus Drekar requires: SEACASNemesis SEACASNemslice SEACASNemspread SEACASEpu SEACASExodiff
mhoemmen
commented
8 years ago Wouldn't it be easier to fix the fortran issue? I think the disable SEACAS comment was just for the demo; not for xSDK in general.
That's right -- I didn't mean to suggest disabling SEACAS altogether. I just wanted to help Lois get the demo done :-)
bartlettroscoe
commented
8 years ago Instead of disabling ALL of SEACAS in xSDK, adding the subpackage disables which we had been discussing prior to the comment about disabling all of SEACAS.
Yes, that would be the idea. I could put the infrastructure in place for this on the Trilinos 12.6 release branch and then if I ran into problems building and testing what was left, I could pass this back of you @gsjaardema. Does that sound like a plan?
gsjaardema
commented
8 years ago Yes. That works.
On Friday, May 20, 2016, Roscoe A. Bartlett notifications@github.com wrote:
Instead of disabling ALL of SEACAS in xSDK, adding the subpackage disables which we had been discussing prior to the comment about disabling all of SEACAS.
Yes, that would be the idea. I could put the infrastructure in place for this on the Trilinos 12.6 release branch and then if I ran into problems building and testing what was left, I could pass this back of you @gsjaardema https://github.com/gsjaardema. Does that sound like a plan?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/trilinos/Trilinos/issues/375#issuecomment-220668272
bartlettroscoe
commented
8 years ago Okay, I will create a new Trilinos GitHub issue to disable SEACAS Fortran subpackages when Fortran is disabled and then work it.
BarrySmith
commented
8 years ago @bartlettroscoe Shouldn't all the packages support -DXSDK_ENABLE_Fortran=OFF It looks like SuperLU_DIst does (or would with a bug fix).
bartlettroscoe
commented
8 years ago Shouldn't all the packages support -DXSDK_ENABLE_Fortran=OFF It looks like SuperLU_DIst does (or would with a bug fix).
It seems that XSDK_ENABLE_Fortran is already supported in the module XSDKDefaults.cmake which is already used by Trilinos or SuperLU (and I would assume SuperLUDist). However, it appears that TriBITS is just setting it as:
$ cd Trilinos/cmake/tribits/
$ find . -name "*" -exec grep -nH XSDK_ENABLE_Fortran {} \;
...
./core/package_arch/TribitsGlobalMacros.cmake:1594: SET(XSDK_ENABLE_Fortran ${${PROJECT_NAME}_ENABLE_Fortran})so if you set XSDK_ENABLE_Fortran=OFF it will just ge overwritten.
Now we could make TriBITS look for the value of XSDK_ENABLE_Fortran set by the user as well. But now we have a problem. If XSDK_ENABLE_Fortran and ${PROJECT_NAME}_ENABLE_Fortran (PROJECT_NAME=Trilinos) are both set, but disagree, then what should happen? (This is a problem with duplicated variables in CMake. These are just global variables that can be set in a variety of ways in a variety of places and it is hard to address inconsistencies like this. So I might need some advice on the best way to handle this.)
Note that the general policy in TriBITS is that when an enable and a disable are inconsistent, then disables trump enables. If we follow this policy in this case, then if XSDK_ENABLE_Fortran=OFF or ${PROJECT_NAME}_ENABLE_Fortran=OFF are set, then Fortran will be disabled (and if the other is ON, then a NOTE will be printed stating what happened.) The downside is that if someone sets XSDK_ENABLE_Fortran=ON, but somewhere else Trilinos_ENABLE_Fortran=OFF is set, then Fortran will be off. That might make some people crazy. But if they just grep the CMake STDOUT they will see that XSDK_ENABLE_Fortran got set to false and why.
Does that seem like a reasonable approach?
bartlettroscoe
commented
8 years ago If we follow this policy in this case, then if
XSDK_ENABLE_Fortran=OFFor${PROJECT_NAME}_ENABLE_Fortran=OFFare set, then Fortran will be disabled (and if the other isON, then aNOTEwill be printed stating what happened.)
I created the TriBITS Issue TriBITSPub/TriBITS#121 to make this the behavior of TriBITS projects (and therefore Trilinos).
gsjaardema
commented
8 years ago @bartlettroscoe Attached is a patch to split the suplib routine into fortran and c versions. This will be needed for the disabling of SEACAS Fortran-specific packages. 0001-SEACAS-separate-suplib-c-routines-into-suplib_c-libr.patch.txt
gsjaardema
commented
7 years ago SEACAS now builds with no warnings with SEACASProj_ENABLE_Fortran:BOOL=OFF
mhoemmen
commented
4 years ago I'm closing this since it's been two years since an update. Please feel free to reopen or open a new issue if it's still not working. Thanks!
It appears that trilinos will not cmake properly without a fortran compiler but it is not clear that the core components of trilinos require a fortran compiler. So is this a bug or the intended functionality?
@jwillenbring @bartlettroscoe @curfman