Error with --try-toolchain

[mvsurf]

Getting the following error when trying the option --try-toolchain=intel,2016b for a intel/2017a easyconfig file:

~> eb --dry-run --try-toolchain=intel,2016b NCO-4.6.6-intel-2017a.eb --robot
== temporary log file in case of crash /tmp/marcov/eb-mT2Kk1/easybuild-o4bE7L.log
ERROR: Irresolvable dependencies encountered: cURL/7.53.1-intel-2016b, flex/2.6.4-intel-2016b, libreadline/7.0-intel-2016b, binutils/2.27-intel-2016b

The Irresolvable dependencies listed here are all available for the GCCcore toolchain.

[ocaisa]

Unfortunately this shortcoming is well known but still a very early work in progress, see #1627

[boegel]

@ocaisa I was sitting next to @mvsurfsara when he ran into this, and asked to open an issue since I think we can do better here with limited extra effort.

Since we're sticking to the same toolchain, just a different version, so we don't have the problem of needing to map subtoolchains between different toolchains.

For some reason, there is no easyconfig generated for cURL, not even with the target toolchain intel/2016. That's definitely a bug, I'm not sure why that happens at all...

Even better would be to map the GCCcore used in intel/2017a to the one used in intel/2016b, and then just replace the version in the cURL easyconfig that's available for GCCcore/6.3.0 (subtoolchain of intel/2017a.)

Also supporting going from foss to intel is more difficult here, since we then (potentially) need to map gompi to iimpi for example (but that almost never happens, it's usually either GCCcore or foss/intel in practice).

[boegel]

I found the problem causing this issue, and I'm working on fix a fix (which is less trivial then I initially thought it was going to be, of course it is...).

The problem is that the while loop in the tweak that is intended to filter out the toolchain & its deps from the list of easyconfigs to tweak is too aggressive: it also filters out dependencies that use a subtoolchain like GCCcore.

Fixing this leads to another problem: the code in tweak_one blindly replacing the toolchain, not taking into account whether dependencies are using a subtoolchain (incl. dummy) or not.

That needs to be fixed too, and that's actually a good thing, since --try-toolchain will (need to be) made somewhat aware of subtoolchains this way, such that dependencies that are using GCCcore still use GCCcore after tweaking (as long as the target toolchain includes GCCcore as well, that is).

[boegel]

partial fix in #2371, but it needs more work...