Trilinos
Trilinos copied to clipboard
trilinos
Dropping support for Makefile.export.* files with TriBITS/Trilinos refactoring to support modern CMake features
CC: @trilinos/framework, @trilinos/trilinos-product-owners
Blocked By: #8401
As part of the imminent TriBITS refactoring described in TriBITSPub/TriBITS#299 to use modern CMake target-based features will that will be enabled by the upgrade of the minimum required CMake (see #8401) be that the current implementation for generating export makefiles (i.e. Makefile.export.* files) will be broken and it may be difficult to bring it back.
We discussed this topic and the topic of dropping support for Makefile.export.* files at the Trilinos Product Leaders Meeting on 12/16/2020. The action items that came out of that were:
- [x] Add an example raw CMake project in
Trilinos/demos/that usesfind_package(Trilinos)and uses some functionality in Trilinos ... See demos/simpleBuildAgainstTrilinos - [x] Create a plan for customers to transition to no
Makefile.export.Trilinosfiles. (I.e., either switch to CMake or manually get the list of libraries you need such as withCMAKE_EXPORT_COMPILE_COMMANDS) ... Plan is for customers to use CMake or manually maintain their link lines (like Sierra does) - [x] Craft and send out an email to various mail lists announcing dropping support for
Makefile.export.Trilinosand get feedback from internal and external customers ... Sent out emails on 5/19/2021 stating support will be dropped on 6/10/2021 - [x] Send out reminder email about dropping support for
Makefile.export.Trilinoson 6/10/2021. - [x] Update documentation on trilinos.github.io related to building against Trilinos (update Find_Trilinos.txt and remove Export_Makefile.txt) ... See PR https://github.com/trilinos/trilinos.github.io/pull/49 ...
- [x] Drop support for
Makefile.export.Trilinosfrom TriBITS and Trilinos 'develop' on 6/10/2021 ... See PR #9284 - [x] Send out one list set of emails to various mail lists announcing that Trilinos 'develop' (as of the merge of PR #9284) no longer supports
Makefile.export.*files. - [x] Talk with Scott Collis about dropping support for
Makefile.export.Trilinos(~~meeting set for 6/22/2021~~ ... pushed back till 7/9/2021).
Create a plan for customers to transition to no Makefile.export.Trilinos files. (I.e., either switch to CMake or manually get the list of libraries you need such as with CMAKE_EXPORT_COMPILE_COMMANDS).
Making this way more general could help: https://gitlab.kitware.com/paraview/paraview/-/blob/master/Clients/CommandLineExecutables/paraview-config.in. That is heavily ParaView-specific, but is an outline of what would be needed for something more generally.
Aw, man. Those things are useful.
@csiefer2, the goal would be to move customers to use CMake for their projects using Trilinos.
Guess that just means I need to learn how to write cmake from scratch for little toy codes that use Trilinos...
Do we have any documentation for that?
Do we have any documentation for that?
Before these changes are pushed into Trilinos, we will have instructions and an example in Trilinos (probably in the demos directory). It's only a few lines of code to pull trilinos into a new cmake app.
Looks like there is some urgency for at least and example using find_pakage(Trilinos) as per #8857. I can't believe there is no documentation or even an hint in Trilinos about how to do this. (In my defense, I did not write any of the CMake code in TriBITS or Trilinos to support TrilinosConfig.cmake. But I will have to rewrite this as part of https://github.com/TriBITSPub/TriBITS/issues/299.)
CC: @rppawlo, @jwillenbring
Turns out an example of how to build against Trilinos using CMake already exists under demos/buildAgainstTrilinos. I have no idea if that still works or not. I did not even know that this example even existed!
I can test and update this example to make sure it works but then we need to protect this in PR testing.
@trilinos/framework, could you consider setting up the PR builds to do an install of Trilinos and then build and test this example project? We need to ensure that example always works and it will also do some level of installation testing.
FYI: PR #8867 takes care of the example of how to build and link against installed Trilinos using CMake. Please give this a review and provide comments there.
@ccober6, @trilinos/trilinos-product-owners,
It is time to drop support for Makefile.export.* files to enable the TriBITS refactor that I am now finally able to dive into (see riBITSPub/TriBITS#367).
I vote that the plan to transition from Makefile.export.* is for downstream customers to use CMake. Any objections to that?
I want to propose that we send out announcements to internal and external stakeholders ASAP saying that support for Makefile.export.* files will be dropped and then go ahead and remove support for them in Trilinos as a trial to see who this impacts. Initially we can disable support in such a way that we could bring it back for a short amount of time but it will not be long once I get into TriBITSPub/TriBITS#299 that it will not be easy to bring it back.
Who do we send out announcements to or should we just disable Makefile.export.* files right away and see who complains? People have been warned about this for a long time.
BTW, the example in:
https://gitlab.kitware.com/paraview/paraview/-/blob/master/Clients/CommandLineExecutables/paraview-config.in
pointed to by @mathstuf above basically creates a mock CMake project that imports a <Package>Config.cmake file (using find_package(<Package>)) and then runs a verbose build and grabs the include directories and link libraries out of the STDOUT. It looks like it would not be too hard to make that work if someone is really passionate about keeping support for the Makefile.export.Trilinos file. (That could be hacked into Trilinos if needed.)
@trilinos/trilinos-product-owners,
To show how long this issue has been discussed, there is a long email thread going back to January 2020 with various internal Trilinos customers that started with the below (redacted) email chain. I can post the full email thread in an internal SNL issue tracker if desired.
From: Bartlett, Roscoe A Sent: Monday, January 27, 2020 1:50 PM To: [redacted] Subject: Makefile.export.Trilinos and Makefile.export.<Package> support?
Hello Trilinos Product Leads,
As was mentioned at the ATDM PI Meeting today, one piece of functionality that has not been tested yet with the Kokkos 3.0 CMake refactoring is the generation of Makefile.export.Trilinos and Makefile.export.<Package> files which is supported by TriBITS as documented at:
- https://tribits.org/doc/TribitsBuildReference.html#generating-export-files
This allows Makefile-based projects to easily use Trilinos installations. This was functionality written years ago, first by Kevin Long, then then extended by Brent P. and maintained a little by Nico S. and myself over the years. (I was the first to add some automated testing for it a few years ago to help protect it on the TriBITS side as part of CASL).
I don’t know how many Makefile-based projects still use generated Makefile.export.Trilinos and Makefile.export.<Package> files but I know that the MOOSE code from INL uses them to link to Trilinos and that is used in the CASL VERA code (which is still be maintained as of now). But with CASL ending, it might be that the post-CASL work will not be depending on MOOSE and MOOSE will not longer be needing to use Trilinos. And they don’t even mention Trilinos, for example, at:
- https://mooseframework.inl.gov/getting_started/installation/manual_installation_gcc.html
So perhaps this is the time to dump support for Makefile-based projects? (I would very much like to dump support for Makefile-based projects from TriBITS in the current refactoring work that I am doing so I would personally welcome this.)
But at the very least, there should be some attempt to poll the Trilinos user community and find out who removing support for Makefile.export.Trilinos and Makefile.export.<Package> files will impact.
Should we create a Trilinos GitHub issue for this?
Thanks,
-Ross
From: On Behalf Of Glass, Micheal W Sent: Monday, January 27, 2020 1:07 PM To: [redacted] Cc: [redacted] Subject: Weekly PI Status Meeting - 01.27.2020
[redacted]
- Siva a. Asked Ross to send cmake/makefiles issues to Trilinos leaders group
[redacted]
@trilinos/trilinos-product-owners, @ccober6,
Any final objections before I do this?
From: Bartlett, Roscoe A Sent: Tuesday, April 27, 2021 1:39 PM To: @trilinos/trilinos-product-owners, @ccober6 Subject: RE: Makefile.export.Trilinos and Makefile.export.<Package> support?
Hello Trilinos Product Area Leads and Product Manager,
I am ready to pull the trigger on removing support for export Makefiles in TriBITS (and therefore in Trilinos) to make room for the modernization of TriBITS as long discussed.
See my comment in:
https://github.com/trilinos/Trilinos/issues/8498#issuecomment-825342514
Any final objections before I post a PR to Trilinos with an updated TriBITS with no support for export Makefiles?
Thanks,
-Ross
Just a few questions:
- Who is dependent on export Makefiles?
- ExxonMobil CRADA is OK. We are going to freeze our version of Trilinos, since the CRADA is finished.
- Others? Are they ready?
- Have you sent out an email announcing this (from your check list above)?
- What is the timeline on this? A few days/weeks?
@ccober6,
Who is dependent on export Makefiles? Others? Are they ready?
The only SNL APP that I know of that was still using export Makefiles was Xyce but they had a plan to fix that. I will ping the PI to make sure they are ready for this.
Have you sent out an email announcing this (from your check list above)?
I have not. What are the right email lists to use for this? [email protected]? Are there any others? Someone please tell me.
What is the timeline on this? A few days/weeks?
A couple of weeks at most. Basically I can't do TriBITSPub/TriBITS#299 without removing support for export Makefiles. Once that refactoring starts (in the next week), then there is no going back. (Yes, there are ways that you could generate Makefile.export.Trilinos that may work like described above but that could take a significant amount of effort. But the plan was to stop supporting Makefile-based projects and only support CMake-based projects.)
@bartlettroscoe
@ccober6,
Who is dependent on export Makefiles? Others? Are they ready?
The only SNL APP that I know of that was still using export Makefiles was Xyce but they had a plan to fix that. I will ping the PI to make sure they are ready for this.
Great!
Have you sent out an email announcing this (from your check list above)?
I have not. What are the right email lists to use for this? [email protected]? Are there any others? Someone please tell me.
I would suggest sending this to [email protected], [email protected] and [email protected]. We probably need to give a time frame to give folks a chance to handle this.
We should also mention this at the SART meeting in two weeks (the meeting was this morning :( ). I have added it to the agenda for 2021-05-11. (https://wiki.sandia.gov/display/TRIL/2021-05-11+SART+Meeting+Notes)
What is the timeline on this? A few days/weeks?
A couple of weeks at most. Basically I can't do TriBITSPub/TriBITS#299 without removing support for export Makefiles. Once that refactoring starts (in the next week), then there is no going back. (Yes, there are ways that you could generate
Makefile.export.Trilinosthat may work like described above but that could take a significant amount of effort. But the plan was to stop supporting Makefile-based projects and only support CMake-based projects.)
Yeah, all the more we should make sure folks have a heads up on this and the timeline.
I would suggest sending this to [email protected], [email protected] and [email protected]. We probably need to give a time frame to give folks a chance to handle this.
@ccober6, okay, I will create a draft email and send to you and the Trilinos Product Area Leads to provide feedback before I send it out for real.
I will create a draft email and send to you and the Trilinos Product Area Leads to provide feedback before I send it out for real.
FYI: I sent out a draft of the email to the Trilinos Product Area Leads and I will get feedback in that email chain.
@ccober6
Shoot, it looks like an important Trilinos customer has not made the transition from Autotools (based on Makefiles) to CMake as hopped and they say early June at the earliest. This would seem to be a major impediment to doing the TriBITS refactoring in TriBITSPub/TriBITS#299 unless we find a way to keep supporting Makefile.export.* files (as described above).
FYI: Xyce is working to switch their daily integration build against Trilinos 'master' from autotools to CMake. There was an issue with using shared libs that caused ugly configure warnings and those warnings were also shown in simpleBuildAgainstTrilinos. I fixed that project in PR #9112 to make those warnings go away and hopefully Xyce can do the same thing.
The goal is to not require use to keep supporting Makefile.export.* files in order to support Xyce.
From: Bartlett, Roscoe A Sent: Wednesday, May 19, 2021 3:08 PM To: @trilinos/trilinos-product-owners Subject: RE: DRAFT: Trilinos dropping support for Makefile.export.Trilinos
Hello All,
From recent conversations with Xyce in [redacted] it sounds like they are very close (weeks away) to switching Xyce over to using CMake for their daily Trilinos integration testing builds (but with Xyce + Trilinos ‘develop’ and Charon + Xyce + Trilinos ‘develop’). Therefore, I think it is time to send out the below draft email to the various Trilinos email lists floating a trial date for removal for support for the Makefile.export.* files. I will float a trial date of June 10, 2021.
I will be sending out the first set of emails later today to see what type of response we get.
-Ross
From: Bartlett, Roscoe A Sent: Wednesday, May 19, 2021 3:59 PM To: [trilinos-developers] Cc: [trilinos-framework] Subject: Trilinos dropping support for Makefile.export.* files
Hello Trilinos Developers,
If you are not using the installed Makefile.export.Trilinos or the package-level Makefile.export.
I am writing this email to announce that as part of a CMake build-system modernization effort, Trilinos will be dropping support for the installed Makefile.export.Trilinos and package-level Makefile.export.
The expectation is that the majority of Trilinos customer projects are (or soon will be) using CMake and can therefore use the CMake command find_package(Trilinos COMPONNETS …) or find_package(<TrilinosPackage>) that pulls in info from the installed TrilinosConfig.cmake and package-level <TrilinosPackage>Config.cmake files.
An updated example project using CMake to pull in an installation of Trilinos is given in:
- https://github.com/trilinos/Trilinos/tree/master/demos/simpleBuildAgainstTrilinos
This change has been discussed in the Trilinos community for over a year with some background mentioned in:
- https://github.com/trilinos/Trilinos/issues/8498
and the technical reasons for this are discussed in:
- https://github.com/TriBITSPub/TriBITS/issues/299
If this change on this time scale will cause a significant impediment to your project, then please let us know ASAP!
Also, please forward this email to anyone who you think might be impacted by this and/or may want to provide some feedback.
Thanks,
-Ross
P.S. It is possible to bring back support for the installed Makefile.export.Trilinos and package-level Makefile.export.
@jwillenbring, can you please approve the email shown below to get sent out to the Trilinos user community?
From: Bartlett, Roscoe A Sent: Wednesday, May 19, 2021 4:06 PM To: '[email protected]'. '[email protected]' Cc: [trilinos-framework] Subject: Trilinos dropping support for Makefile.export.* files
Hello Trilinos Users,
If you are not using the installed Makefile.export.Trilinos or the package-level Makefile.export.
[same as above]
Okay, I think I have gotten emails sent out to all of the Trilinos developer and user email lists that @ccober6 pointed me to offline (two examples are shown above).
CC: @keitat, @ccober6
Excellent news. I can happily report the Xyce + Trilinos 'develop' and Charon + Xyce + Trilinos 'develop' integration efforts have been upgraded to use CMake for building Xyce and are no longer requiring Makefile.export.* files from Trilinos! (See internal issue 216 for details.)
Also, I only got back one response to my emails from 5/19/2021 shown above from an internal customer about concern for dropping support for Makefile.export.* files by 6/10/2021. @ccober6 responded to that customer and I believe the problem is mittigated.
Therefore, I don't see any impediment to dropping support Makefile.export.* files from Trilinos 'develop' on 6/10/2021.
@ccober6, do I need to send out another email to any email lists warning people about dropping support for Makefile.export.* files from Trilinos 'develop' on 6/10/2021? I don't want to spam people but I also don't want to catch people off guard. (The truth is that no matter what you do, some people will feel like you are spamming them and other people will feel like you dropped a bomb on them.)
@bartlettroscoe I am assuming you meant 06/10/2021. I agree about spamming folks, but still keeping them informed. I would suggest sending a reminder on 06/07/2021. There is a SART meeting on 06/08/2021, and I have added a reminder to the agenda. I would just follow-up after the fact letting folks know it is done. Does this sound reasonable?