-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add a "--fast" flag to update_and_rebuild_libmesh.sh? #6741
Comments
How about add another one |
I don't understand... If you maintain your own libmesh outside the submodule in MOOSE, then you aren't running this script. It is hardcoded to |
libMesh is still under moose/libmesh, just checked out manually. That is what I did. moose/libmesh to me a convenient place. |
Wow, OK, that is a really special and confusing case. Doesn't your |
Yes, |
I like this idea. While you're at it, are you planning to have it just build opt? That would help ease the pain of the build on the clusters when we get rid of the prebuilt libmesh since most of the time when people are building on the cluster, I'd guess that they just want opt. |
I don't mind the idea, but I doubt it will save people much time. When we do libMesh updates surely a critical header or two have changed in the intervening time that will cause a whole library rebuild no matter what. @bwspenc the script honors the |
While you're at it, could you add a --fast flag to MOOSE too? I'd like it On Wed, Apr 13, 2016 at 9:47 PM Derek Gaston notifications@github.com
|
@permcody Yeah, like the 'turbo' button on my computer. |
The --fast flag skips the steps of removing the build directory and configuring libmesh, so we do not allow other configure flags to be passed in addition to --fast. We also check that there is an pre-existing build directory when the user passes --fast, you can't do --fast the first time you build libmesh. Refs idaholab#6741.
The --fast flag skips the steps of removing the build directory and configuring libmesh, so we do not allow other configure flags to be passed in addition to --fast. We also check that there is a pre-existing build directory when the user passes --fast, you can't do --fast the first time you build libmesh. Refs idaholab#6741.
There are still old packages out there, and people who build their own PETSc without all the bells and whistles, so this is a no-go. Refs idaholab#6741, idaholab#6836.
The --fast flag skips the steps of removing the build directory and configuring libmesh, so we do not allow other configure flags to be passed in addition to --fast. We also check that there is a pre-existing build directory when the user passes --fast, you can't do --fast the first time you build libmesh. Refs idaholab#6741.
There are still old packages out there, and people who build their own PETSc without all the bells and whistles, so this is a no-go. Refs idaholab#6741, idaholab#6836.
This will somewhat reduce the amount of recompilation required after libmesh updates, although the main benefit will be to people who recompile libmesh more frequently, but do so via the update_and_rebuild_libmesh.sh script instead of using custom build scripts. @dschwen and I confirmed that the -C flag does the right thing (only copying files which have changed) on both Linux and Mac. Refs idaholab#6741.
@jwpeterson |
Description of the enhancement or error report
We run
rm -rf build
every time someone runs theupdate_and_rebuild_libmesh.sh
script. This, combined with the fact that we always build three methods (opt, dbg, oprof), makes libmesh updates very painful for users. We should be able to get away with just rebuilding libmesh (without cleaning) after the submodule update. We could do this by default or add a flag that conditionally enables it.Rationale for the enhancement or information for reproducing the error
To reproduce: just run update_and_rebuild_libmesh.sh on a 2 or 4-core computer...and wait.
Identified impact
This will impact almost everyone who uses MOOSE, by speeding up their libmesh update times.
The text was updated successfully, but these errors were encountered: