<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Aldi,</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I believe spack is the closest to what I need. However, all these<br>solutions (hunter, conan, spack...) have perhaps their strongest focus<br>in packaging, dependencies, automatic downloads, etc... while I prefer<br>to do all such tasks myself.  I prefer to not have packages, just</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
download the source in the original developer provided form, untar it,<br>
and to even build it on my own, following the developer instructions.<br></blockquote><div><br></div><div>That is exactly what Spack does.  A Spack "package" is really just a recipe that automates those tasks.  I think of the Spack recipe as a Python encoding of the English-language build instructions.  In fact, when I want to know how a package is built, I prefer to look at the Spack recipe.  It's more concise than English, and frequently more complete.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As I said, I think spack is the closest. However, I feel it tries to<br>
automate too much the build. Yes, it gives you a lot of customization<br>
options, but I'm not sure the complexity is worth the effort.<br></blockquote><div><br></div><div>Spack should work out-of-the-box without customizing things.  Many of the features --- shell integration, environment modules, etc --- are not strictly necessary.</div><div><br></div><div>You might be interested in the `spack setup` command, which currently works with CMake-based projects.  It is especially good for projects you're developing, or otherwise already have the source code in your directory.  I use this feature to configure all the projects I'm working on.  To use Spack setup, you do the following:</div><div><br></div><div> 1. Download and untar the software yourself, in your favorite location.  (This is especially useful for development versions that don't yet have a tarball).</div><div> 2. Run `spack setup`.  This creates a script whose purpose it is to call CMake with appropriate options for dependencies and install location.</div><div> 3. Run the Spack-generated script in place of CMake</div><div> 4. Build and install yourself.</div><div><br></div><div><a href="http://spack.readthedocs.io/en/latest/workflows.html?highlight=spack%20setup">http://spack.readthedocs.io/en/latest/workflows.html?highlight=spack%20setup</a><br></div><div><br></div><div>Here's an example...</div><div>$ tar xvfz myproject.tar.gz</div><div>$ cd myproject</div><div>$ spack setup myproject@develop</div><div>$ mkdir build</div><div>$ cd build</div><div>$ ../spconfig.py ..   # Calls through to CMake</div><div>$ make</div><div>$ make install</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think that by using this approach, I could reconsider moving to<br>
spack in the future (I'd likely have to install all packages from<br>
scratch if I move to spack later, but my directory hierarchy will end<br>
up being the same, so all the work I do now -writing code and<br>
projects- would be reusable without modification).<br></blockquote><div><br></div><div>With an auto-builder, I've found that re-installing everything is no big deal.  I can re-install 100 packages in a few hours of wall time, and no more than a few minutes of my time.</div><div><br></div><div>-- Elizabeth</div><div><br></div></div></div></div>