@mathstuf: can you look at this one?

@adamjstewart: At this point, we can probably add some logic to make CMake (and other build dependencies) build with the default front-end compiler rather than a "custom" compiler. This would probably solve a lot of problems with bringing in build dependencies, in that it wouldn't require build dependencies to work with fancy back-end compilers. What do you think?

@tgamblin I would very much approve of that. I really don't care what compiler build dependencies are built with, so if they always just built with GCC, I would have fewer duplicate CMake installations.

There are nightly dashboards for CMake with the Intel compiler: 11.0 for 32-bit Windows and 64-bit, and 12.0 on OS X 10.7. I don't see any Linux builders though. What version of the compiler?

Oh, and an Intel 15.0 for 64-bit Windows build as well.

@mathstuf I had this problem with Intel 16.0.3 and 15.0.0. This is on linux-centos6-x86_64 btw. I can try to dig up build logs if you want.

+1. Build logs would be nice (but shouldn't block the PR).

Moving discussion of the problems with Intel to #1415. If we discover a solution and this PR hasn't been merged yet, I'll add it here. Otherwise, this PR should be ready to merge as is.

@adamjstewart: Is there a reason we need variants for all the system libraries? Couldn't you just consolidate that down to a single variant (systemlibs or something)? I ask because the mechanism I would like to eventually use for stuff like this is auto-detection of system libs and integration with packages.yaml, which would mean you wouldn't need variants for any of the libraries; Spack would just know to resolve some stuff with system libraries, though the externals mechanism.

@tgamblin We don't need variants for everything. The way I see it, most packages like these have 4 options:

1. Link to Spack-installed libraries
2. Link to system libraries
3. Link to the external libraries that come with the package tarball
4. Don't build support for these libraries

Each of these options has pros:

1. Most control over versions of dependencies
2. Don't need to reinstall everything
3. The versions that come with it are most likely to be compatible
4. Don't build what you don't need

And each of these options has cons:

1. Requires a lot of dependencies to be built successfully
2. May or may not exist on the system
3. Might have to patch things twice, may not work with newer compilers
4. You might regret lacking that support later

What would be the best option here? A boolean variant only lets me choose 2 of these options. Of course, we don't need any variants at all if we just want to always link to Spack-installed libraries. I would be fine with that.

@adamjstewart I just read the thread... I think we built cmake just fine with Intel 16.0.3. In can give you more information tomorrow, in case you need it...

@becker33 The non-boolean variable support isn't great yet as we've discussed (#1341). There's currently no way to list the available options. Do we even want to provide all 4 of those possibilities?

@alalazo see #1415. I'll add that patch to this PR and test it out in a minute.

Alright, CMake builds with Intel again thanks to @mathstuf! As for the variants, what do we want to do here? My original thought was that variants are cheap and if anyone runs into problems with a dependency they can always disable it. Do we want to always build with Spack? Do we want an all-or-nothing variable? Do we want to use non-boolean variants?

@tgamblin What else needs to be done to get this PR ready to merge? Have we decided on how we want these dependency variants to work?

Ping @tgamblin

@adamjstewart: sorry for the delay. RE: variants, I'd kind of rather have systemlibs variant if you really want to allow building cmake with external deps. On my nice-to-have list is auto-detection and auto-registering of system libraries like these in externals, so that you don't have to do stuff like this, but systemlibs seems clearer.

Do you ever do something different from options 1 or 2? Do we need to support 4 options? My gut feeling is that users aren't going to care in this instances, as long as CMake builds. I would lean towards building with spack libs by default but could go both ways on that.

@tgamblin Honestly, I'm fine with having no variants and only supporting option 1. I feel like this practice is common in other packages. But if you want I can just do what I have already and replace all of the variants with a single systemlibs variant.

@adamjstewart: Maybe I'm not keeping up enough with all the packages - is it common to have options for using system dependencies, or just common to have optional dependencies?

A systemlibs variant would be great.

@tgamblin For packages that require something, either from a system lib, tarball lib, or Spack lib, I think it usually either doesn't include the dependency (thereby using the system lib or tarball lib) or lists the dependency as required (using the Spack lib). If the dependency isn't actually required at all, it's more common to see it listed as an optional Spack dependency enabled/disabled by a variant. But all of that is irrelevant, because we can write packages the way we think they should work; not the way they've been written in the past.

I'll switch everything to systemlibs unless there are any other opinions.

@adamjstewart: sounds good. FWIW, I would also be ok with just option 1 :).

The only problem I see with only having option 1 is that we're adding new dependencies to a package, and we have no idea whether or not they'll break for others, especially on macOS. If you recall, we had some problems after I added new dependencies to the git package. Having a variant there to allow people to disable the dependencies if they need to might be smart.

Of course, that might just uncover a new bug in one of these packages that we could solve. Why play it on the safe side when you can find and fix new bugs. It's really up to you, I don't care. I just figured we should rely on Spack since there's no guarantee that the system libs are present at all.

@adamjstewart: let's go with the variant then, so there's a workaround. Ideally (and thanks to things like #1576) we'd be able to hash this stuff out in CI beforehand, but we don't have that luxury at the moment

I'll get to this in a minute. Let me just finish fixing these documentation docstring bugs.

I just took a look at CMake's bootstrap script and I guess I wasn't clear on what system and no-system meant. From ./bootstrap.sh --help:

  --system-libs           use all system-installed third-party libraries
                          (for use only by package maintainers)
  --no-system-libs        use all cmake-provided third-party libraries
                          (default)
  --system-curl           use system-installed curl library
  --no-system-curl        use cmake-provided curl library (default)
  --system-expat          use system-installed expat library
  --no-system-expat       use cmake-provided expat library (default)
  --system-jsoncpp        use system-installed jsoncpp library
  --no-system-jsoncpp     use cmake-provided jsoncpp library (default)
  --system-zlib           use system-installed zlib library
  --no-system-zlib        use cmake-provided zlib library (default)
  --system-bzip2          use system-installed bzip2 library
  --no-system-bzip2       use cmake-provided bzip2 library (default)
  --system-liblzma        use system-installed liblzma library
  --no-system-liblzma     use cmake-provided liblzma library (default)
  --system-libarchive     use system-installed libarchive library
  --no-system-libarchive  use cmake-provided libarchive library (default)

Previously, we weren't specifying anything, and therefore using the cmake-provided libraries. We were never using the system installed libraries. By using system and adding all of the libraries as dependencies, we link to the Spack-built versions. Of course, if we used system and didn't add the dependencies, then we would actually link to the system installed libraries.

@tgamblin What do we want to do here?

On the other hand, libarchive works a bit differently than cmake. You either build --with-<lib> or you build --without-<lib>. If you build with and don't add the dependency, you link to the system version. If you build with and add the dependency, you link to the Spack installation. If you build without, you don't build support for that particular compression algorithm.

@tgamblin What do we want to do here?

@adamjstewart: I think we should strive for --system-libs (as I think sharing could make the build faster) but I'd be ok with --no-system-libs for reliability.

@adamjstewart: for libarchive, I'd just depend on the spack dependency. My preference is to always use the spack dependencies.

What would you call the variant for CMake? It's not really a system library if it's built with Spack. +spacklibs defaulting to True, or cmakelibs defaulting to False?

What about standardizing on ownlibs for this kind of thing so that we could potentially set it for many packages in packages.yaml?

Sure.

Alright, now before I get myself in trouble, let me just test this out from a clean Spack installation.

@tgamblin Ran into a package whose make check failed on my laptop, so I decided to play it safe and wrap all of the make check in self.run_tests. It builds fine, but doesn't seem to be linking to libjsoncpp.so:

$ ldd -r /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/cmake-3.6.1-tufdqut6xse44c33vmkkulb3ydm7rhca/bin/cmake 
    linux-vdso.so.1 (0x00007fff871e5000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f62ab055000)
    libexpat.so.1 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/expat-2.2.0-gfaoztpxp5v4tj3lhnet4rehuakejdbq/lib/libexpat.so.1 (0x00007f62aae2a000)
    libz.so.1 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/zlib-1.2.8-op4qu2weutekf7vsftu3giioaj5tjsho/lib/libz.so.1 (0x00007f62aac10000)
    libarchive.so.13 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/libarchive-3.2.1-46mfh2mac5ecea2cr72hruitqyu65pwh/lib/libarchive.so.13 (0x00007f62aa95f000)
    libcurl.so.4 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/curl-7.50.1-6yb24i7mgesjky6fp2orszdnvg2ewsjq/lib/libcurl.so.4 (0x00007f62aa6f9000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f62aa372000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f62aa068000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f62a9e50000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f62a9a8e000)
    /lib64/ld-linux-x86-64.so.2 (0x000055628549a000)
    libnettle.so.6 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/nettle-3.2-3732pbasycs63kfapq262qv6jrmzx6bb/lib64/libnettle.so.6 (0x00007f62a9856000)
    liblzo2.so.2 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/lzo-2.09-n44sb3raiopgyrzxagic5xqilaiogwmn/lib/liblzo2.so.2 (0x00007f62a9634000)
    liblzma.so.5 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/xz-5.2.2-tu2dqdo55u5r7xc4zkkbzcq3kwceseig/lib/liblzma.so.5 (0x00007f62a940d000)
    liblz4.so.1 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/lz4-131-k5cqwrtzhtfnc7gil5lf7wupydtscnc7/lib/liblz4.so.1 (0x00007f62a91f4000)
    liblzmadec.so.0 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/lzma-4.32.7-eiaow7ml7thgkvavyy2e2umnxt3c7pak/lib/liblzmadec.so.0 (0x00007f62a8ff0000)
    libbz2.so.1.0 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/bzip2-1.0.6-fpi4vkw4w5rofpihlnv3ifpmpkd56qc4/lib/libbz2.so.1.0 (0x00007f62a8ddf000)
    libxml2.so.2 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/libxml2-2.9.4-yyiskolihcehe7ibnqgbley6sf6jrhvo/lib/libxml2.so.2 (0x00007f62a8a7a000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f62a885e000)
    libssl.so.1.0.0 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/openssl-1.0.2h-dvmmnfrk2hbppwl6hhrpdjjlldtbcntv/lib/libssl.so.1.0.0 (0x00007f62a85eb000)
    libcrypto.so.1.0.0 => /home/ajstewart/spack/opt/spack/linux-fedora24-x86_64/gcc-6.1.1/openssl-1.0.2h-dvmmnfrk2hbppwl6hhrpdjjlldtbcntv/lib/libcrypto.so.1.0.0 (0x00007f62a8197000)

I also tried being more specific than --system-libs:

'--system-curl',
'--system-expat',
'--no-system-jsoncpp',
'--system-zlib',
'--system-bzip2',
'--system-liblzma',
'--system-libarchive'

That doesn't seem to link to jsoncpp either, but if it isn't working now, I don't think it was working before. Should be safe to merge I think.

Just noticed in the RPATH documentation it mentions a way to add paths to the RPATH like py-pyside does. I'm going to try this out for CMake and see if I can get it to link to jsoncpp.

False alarm. The reason that CMake didn't appear to be linked to libjsoncpp is that if you build with --no-system, CMake builds static copies of all of its dependencies. @tgamblin I believe this PR is ready to merge now.