Our default installation --prefix is /usr/local

[jwpeterson]

If a user specifies no --prefix during configure, the prefix currently gets set to /usr/local. This is kind of bad for a few reasons:

1. The list of things we install:

   Make.common
   bin/
   contrib/
   etc/
   examples/
   include/
   lib/
   share/
   

   includes some non-standard files and directories (Make.common, contrib, examples) that people probably don't want in /usr/local.

2. It is difficult to uninstall libmesh since the various bits are spread out all over the place in /usr/local instead of in a single directory.

3. Finally, if you look at the list of things we actually install to lib/:

   libmesh_dbg.0.dylib
   libmesh_dbg.dylib -> libmesh_dbg.0.dylib
   libmesh_dbg.la
   libmesh_opt.0.dylib
   libmesh_opt.dylib -> libmesh_opt.0.dylib
   libmesh_opt.la
   libnetcdf.11.dylib
   libnetcdf.7.dylib
   libnetcdf.a
   libnetcdf.dylib -> libnetcdf.11.dylib
   libnetcdf.la
   libnetcdf.settings
   pkgconfig
   

   it's possible that the libnetcdf ones will actually overwrite existing netcdf libraries on the system of the same name.

As for choosing a better default, the main question is whether it should be a system location (/opt/libmesh, /usr/local/libmesh, etc.) or a user location ($HOME/.local/libmesh, $PWD/installed, etc.). I'm leaning toward the latter, because it can be frustrating to get a "make install" failure from a script or on a system where you aren't an admin, but I don't feel too strongly about it either way.

[pbauman]

This is the default for any project that uses Autotools for their build system. I would be hesitant to change it, honestly. I agree with all your points, but I also would hate to surprise someone with a different default. Yes, they could read the documentation, but then they'd also see the documentation for --prefix. That said, I don't feel all that strongly about it one way or another. If there is a consensus of changing the default, I too would also suggest a user location so it's easier to remove as well as helping a novice user by not requiring sudo (I could see someone sudo'ing make install without knowing what they're doing).

[roystgnr]

Yeah, part of the advantage of using a standard automake configure script is that people know what to expect with standard automake configure scripts, and I'd rather not break that. If they learn "prefix defaults to /usr/local" the hard way from libMesh, that sucks, but it's a lesson they can apply to literally ten thousand other projects.

On the other hand, you've pointed out a bunch of non-standard things we're doing that we can fix!

Make.common and examples/ belong in share/libmesh/, not at the top level.

I'm not sure why we're installing our own contrib/bin/libtool, but even if there's a good reason, it belongs in bin/.

If "make uninstall" doesn't work with libMesh then we should figure out why and fix it.

Our inability to detect and use an external netcdf is getting to be more and more of a hassle, and we should change that soon.

[jwpeterson]

Yeah, part of the advantage of using a standard automake configure script is that people know what to expect with standard automake configure scripts

I don't know, I've been using automake for several years now and was actually surprised to discover the default was /usr/local. Also while this "standard" may be applicable to the typical GNU software package that is using automake, I don't know how relevant it is for us.

If "make uninstall" doesn't work with libMesh then we should figure out why and fix it.

I will test this, but I don't think "make uninstall", even if it works, is actually sufficient here. It's easy to imagine someone first removing their build and/or source checkout directories and only then realizing they also need to uninstall the libraries/headers and being stuck with libmesh files spread out all over the place in /usr.

[jwpeterson]

FWIW, make uninstall doesn't work quite right. It leaves behind the "dbg" versions of stuff for me (I also tried METHODS='dbg opt' make uninstall and METHOD=dbg make uninstall to no avail) as well as a bunch of empty directories (see complete list below). There may be a simple fix for this in our automake files but I don't know what it is off the top of my head...

ls -l $LIBMESH_DIR/
Make.common

/Users/petejw/projects/libmesh_git/installed/bin:
amr-dbg
calculator-dbg
compare-dbg
fparser_parse-dbg
getpot_parse-dbg
meshavg-dbg
meshbcid-dbg
meshdiff-dbg
meshid-dbg
meshnorm-dbg
meshplot-dbg
meshtool-dbg
output_libmesh_version-dbg
projection-dbg
solution_components-dbg
splitter-dbg

/Users/petejw/projects/libmesh_git/installed/contrib:
bin

/Users/petejw/projects/libmesh_git/installed/etc:
libmesh

/Users/petejw/projects/libmesh_git/installed/examples:
adaptivity
adjoints
eigenproblems
fem_system
introduction
mesh_transfer
miscellaneous
optimization
reduced_basis
subdomains
systems_of_equations
transient
vector_fe

/Users/petejw/projects/libmesh_git/installed/include:
Eigen
boost
libmesh
unsupported

/Users/petejw/projects/libmesh_git/installed/lib:
libmesh_dbg.0.dylib
libmesh_dbg.dylib -> libmesh_dbg.0.dylib
libmesh_dbg.la
pkgconfig

/Users/petejw/projects/libmesh_git/installed/share:
man
reference_elements

[jwpeterson]

All that said, nothing will ever beat the simplicity of being able to do rm -rf $LIBMESH_DIR when everything is in a nice, self-contained installation directory.

[roystgnr]

All that said, nothing will ever beat the simplicity of being able to do rm -rf $LIBMESH_DIR when everything is in a nice, self-contained installation directory.

What's the IT equivalent of "But I could have sworn it wasn't loaded!"? If you've got users running with write access to /usr subtrees, and using "make install" without having specified where the installation should go and without wondering where it will go by default, I'm pretty sure the last thing you want to teach them is to use rm -rf willy-nilly in combination with environment variables.

That said, I'm not in favor of changing our default prefix, but I'm not going to fight it either. AC_PREFIX_DEFAULT() is simple enough, and anyone who really wants /usr/local/ can set it manually. What we really ought to do is make sure that "make install prefix=/usr/local/" works, and then anybody who is surprised by our change will be able to fix it without reconfiguring.

Let's definitely choose a non-system location if we change the default. I kind of like $PWD/installed, actually; works with VPATH, doesn't add top-level clutter to their home directory, and makes it harder to mix up different versions/configurations.