Make update_and_rebuild_libmesh.sh script more libmesh development friendly

[bwspenc]

Description of the enhancement or error report

If I need to modify libmesh, I often find it most convenient to just work in the version that's in my submodule if my project is already set up with libmesh as a submodule. I have to hack the update_and_libmesh.sh script every time I do that, and it would be nice to not have to do that.

Rationale for the enhancement or information for reproducing the error

I'd like to see two things:

1. Add an option to the script that skips the git submodule update. (--skip_update?). I realize that the script would no longer be updating and rebuilding libmesh, so maybe that's a little silly, but nevertheless useful.
2. Add INSTALL="which install` -C" to the configure line so that re-building libmesh wouldn't require a rebuild of everything in MOOSE (or maybe make that an option if that has detrimental effects for regular builds). I was told that the -C option is mac-specific, and that -p is the equivalent on linux, but I looked at the man page for install on a linux box, and it looked to me like -C and -p are supposed to behave the same on both of those platforms. Maybe someone else knows more.

   Identified impact

Limited to scripts/update_and_rebuild_libmesh.sh

[dschwen]

Why? That script is for end users and I think we should optimize it for that propose. For developing I suggest to simply set LIBMESH_DIR.

[bwspenc]

Simply set LIBMESH_DIR and then ... use your own personal script to configure and rebuild libmesh? It seems like it would make a lot of sense to have a unified system for everyone to use to build libmesh, regardless of whether they are using or developing in libmesh. That way we wouldn't all need our own libmesh build scripts. I don't find myself developing in libmesh that often, but when that need arises, it's always a pain to remember how to build it. If there's an easy, standard, preferred way to build libmesh when you're modifying code in it that I'm not aware of, somebody please fill me in.

[dschwen]

You configure it once and then just run make && make install in the build directory...

On Thu, Jun 2, 2016 at 8:39 PM Ben Spencer notifications@github.com wrote:

Simply set LIBMESH_DIR and then ... use your own personal script to configure and rebuild libmesh? It seems like it would make a lot of sense to have a unified system for everyone to use to build libmesh, regardless of whether they are using or developing in libmesh. That way we wouldn't all need our own libmesh build scripts. I don't find myself developing in libmesh that often, but when that need arises, it's always a pain to remember how to build it. If there's an easy, standard, preferred way to build libmesh when you're modifying code in it that I'm not aware of, somebody please fill me in.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7146#issuecomment-223477063, or mute the thread https://github.com/notifications/unsubscribe/AAMWPrQsJIS9865GkIi2m8FhbfayPNj_ks5qH5PUgaJpZM4ItF-P .

[andrsd]

@bwspenc libMesh uses the 3 step build: ./configure; make; make install. There is not anything special to it. If you do not remember the configure line: head config.log in the build directory. Then, just make && make install. Or just plain make install - that should work as well. The ./configure is needed only when the build files change, so I run it only when I pull from the upstream, no need to configure before each make...

[bwspenc]

Sure, but where are you guys getting your configure options? I usually copy/paste them from the MOOSE update_and_rebuild_libmesh.sh script, which just seems wrong. I'm just saying that it would be useful if that script were flexible enough to allow it to be used both for the standard usage as well as for libmesh development. What if we split it into two scripts: a rebuild script, and an update and rebuild script that calls the rebuild script? Then you could use the rebuild script to configure and build your own libmesh if you wanted to do that independently of the git submodule update business.

[friedmud]

@bwspenc you know about the --fast option for that script, right? Would it be fine if --fast didn't update the submodule and basically just did a make? (I kind of think it's an oversight that --fast currently tries to update the submodule... that's basically just a bug)

[bwspenc]

@friedmud Yes, I know about --fast, and I agree that it probably shouldn't update. The problem with --fast is that it doesn't do the configure. My main point here is that it would be nice if we could use that script to configure a libmesh without doing the git submodule stuff, so --fast wouldn't work.

[friedmud]

How about we add a --configure that only does configure... and to me --fast wasn't really the right name... I would prefer --compile that only compiles...

Basically this:

What most users will do:

./update_and_rebuild_libmesh.sh

Just update the submodule

./update_and_rebuild_libmesh.sh --update

Just configure

./update_and_rebuild_libmesh.sh --configure

Just compile

./update_and_rebuild_libmesh.sh --compile

[bwspenc]

@friedmud That's perfect. Alternatively, we could have 4 scripts: 3 that do the individual steps, and then have the existing script call those 3. Either way is fine, just an implementation choice. I'm really interested in doing this in conjunction with using the -C option for install. It would allow you to go into your libmesh directory and hack files, and then just run the script with the compile option, which would trigger a make install for libmesh. You could modify a file in libmesh and rebuild moose without rebuilding everything, and if it's done right, it should work regardless of whether your libmesh is a submodule.