I could build and install with GCC and all variants enabled, as well as all variants disabled. Compilation of the interpreter with ICC was also successful, but when building the core database, the interpreter failed with a segmentation fault (so it could not be installed with ICC). I am not sure whether that is a problem of the setup of our supercomputer. Should I include a conflicts_with("%icc") in the package?

Because some dependencies (e.g. pkg-config) have multiple providers, and the preferred version of libunwind is outdated, I could not install the package in "vanilla" setup, but had to specify dependency spec (^libunwind@2018.10.12 ^pkg-config). Should this be somehow addressed in the package, or are those issues of the dependency resolution?

These things could be addressed in the package if you want. You could also report these to the developers and ask them to take a look and see if they can fix it upstream.

Is there a way to specify a "soft preference" of dependency packages (version preferences, virtual package providers)? From what I understood, libunwind is incompatible with apple systems and I could not test the apple equivalent (which seems to be a stub for the library included in clang, but I'm not sure about that). So I would prefer to have the hard dependency limited to the virtual packages until I know that the build actually fails.

Concerning the icc build I might have to do a bit more research, because Intel has an article on their page showing swipl with icc and openmp, so this might not be a general problem.

https://software.intel.com/en-us/articles/building-and-probing-prolog-with-intel-architecture

I would lean towards disabling icc builds for now. The other dependencies I would prefer to keep as they are. Especially since the manual additions I had to make to the spec are related to weirdness encountered during concretization.

When concretizig without ^libunwind, I get

Error: There are no valid versions for apple-libunwind that match ':'

When trying to concretize without ^pkg-config, I get

Multiple providers found for 'pkgconfig':

but spack config get packages shows

 all:
    compiler: [...]
    providers:
      ...
      pkgconfig: [pkgconf, pkg-config]
      ...
      unwind: [libunwind]

I don't even depend on 'pkgconfig' at all (only on the 'pkg-config' package) and apple-libunwind is not a provider for unwind in my configuration, so neither of these concretization errors should be occuring. For the 'pkgconfig' error I suspect another dependency in the tree, but the apple-libunwind error seems highly suspect.

EDIT:
Btw, I can squash the commits together if you prefer that.

Is there a way to specify a "soft preference" of dependency packages (version preferences, virtual package providers)? From what I understood, libunwind is incompatible with apple systems and I could not test the apple equivalent (which seems to be a stub for the library included in clang, but I'm not sure about that). So I would prefer to have the hard dependency limited to the virtual packages until I know that the build actually fails.

No, but you can do something like:

depends_on('foo')
depends_on('foo@1.2.3:', when='platform=darwin')

so there is a "hard preference" only on some systems.

When concretizing without ^libunwind, I get

Error: There are no valid versions for apple-libunwind that match ':'

When trying to concretize without ^pkg-config, I get

Multiple providers found for 'pkgconfig':

These are bugs in Spack's concretizer that @tgamblin is working on fixing, not bugs in your package.

Btw, I can squash the commits together if you prefer that.

Don't worry about it, I squash all commits automatically when I merge.

I this case there are no further adjustments on my mind. Thanks for the anwers.