0

I'm trying to build HSL's MA57 library, and to do so, it requires METIS. I've downloaded the .tar files to my Downloads folder, but where do I actually "build" the libraries (and subsequently store the compiled files) on a Mac? Is there a best practices location, like usr/local?

jjjjjj
  • 325
  • 1
  • 9
  • 1
    I would highly recommend using homebrew on the mac to build if you can for any standard science libraries and following their directory conventions as they seem to work well and are largely recognized. I was not aware of the distinction that @rchilton1980 mentioned which is interesting. – Kyle Mandli Jan 23 '18 at 14:58
  • Thanks -- this project using homebrew seems to install them to usr/local – jjjjjj Jan 23 '18 at 16:16

1 Answers1

1

I don't think there's any one right answer here. I tend to put non-system libraries in /opt, then add link directives for them manually to the Makefiles etc of whatever apps are looking for them (eg, add -L/opt/path/to/metis and -lmetis to the Makefile of MA57). It's a compromise between putting it somewhere easy to find, but trying to be hygienic and keep your installs out of the system packages. This is probably a little old school, so ymmv.

See also, https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local

rchilton1980
  • 4,862
  • 13
  • 22
  • Thanks, and to better understand nomenclature, does opt mean "optional"? I couldn't find additional detail under man hier but am getting that vibe from this Q – jjjjjj Jan 23 '18 at 03:10
  • 1
    That's what I have always taken it to mean, but I actually don't know for certain. – rchilton1980 Jan 23 '18 at 03:13
  • Last question: what's the -l mean in your path -l/opt/path...? – jjjjjj Jan 23 '18 at 03:14
  • 1
    It's not a path, that's a .. link directive? Essentially a compiler (linker) flag, directing gcc or clang to add /that/path/there to the search. Similar effect as appending to LD_LIBRARY_PATH, but perhaps a little less permanent. There is a similar one for include searches, `-I'. – rchilton1980 Jan 23 '18 at 03:17
  • 1
    Practice makes perfect. Unfortunately, I find this is the sort of thing you tinker with maddeningly until it works, then promptly forget everything for next time. I even messed it up in my answer .. adding linker paths uses the -L flag, while linking itself uses -l. See https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html – rchilton1980 Jan 23 '18 at 03:19
  • As personal preference, I tend to create an "installs" directory in my home directory that has "bin", "include", "lib", and "share" directories inside it. I then add this "~/installs" directory to my CMAKE_PREFIX_PATH (think of it as a default search path for cmake packages). This allows me to "install" software into a predictable location on machines where I don't have sudo privileges, and the build process doesn't change when I clone my repositories between different machines. I prefer not to touch the system directories so I have complete control over the versions of libraries I link to. – Tyler Olsen Jan 23 '18 at 05:14
  • And to follow on to my last comment, you really shouldn't be writing your own Makefiles unless your projects are extremely small with only a few dependencies. For me, using a build system generator like CMake greatly reduces how fragile my builds are and allows me to configure, compile, and install software in a much less ad-hoc manner. To learn how to use modern (post v3.0, though there's no reason not to stay with the latest version) CMake, I'd recommend this tutorial, which has a stripped down project with explanation: https://rix0r.nl/blog/2015/08/13/cmake-guide/ – Tyler Olsen Jan 23 '18 at 05:26