Checking release notes I can see that pgCC was removed in PGI 16, but I am not sure if it was still recommended in 15.x. IIRC both pgCC and pgc++ existed but pgc++ was already recommended. I'll check later.

EasyBuild framework unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/3023/console for more details.

Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do.

yeah, time to ditch Jenkins...

Jenkins: test this please

EasyBuild framework unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/3024/console for more details).

This pull request is now ready for review/testing.

Please try and find someone who can tackle this; contact @boegel if you're not sure what to do.

It seems they introduced the "new" pgc++ in 2012:

https://www.pgroup.com/lit/articles/insider/v4n1a2.htm

It seems like pgCC was the only possibility prior to 2012, it coexisted with pgc++ until end of 2015, and disappeared in 2016 (I haven't checked the specific versions, this is just a rough timeline). The questions are:

• Do we want to support something older than 2012? (please say no......)
• Do we want to allow to choose between pgc++ and pgCC for toolchains using PGI>=12 and PGI<16? I'd say also no.

On the telco I just wanted to raise the issue that pgCC seemed to be the preferred choice for some people using older releases. Since this is a new addition to EB, I'd say it makes sense to implement it looking to the future, not the past.

I asked PGI support for which versions pgc++ is the recommended compiler to use, and whether we should go with pgCC or pgc++ for PGI 15.x.

I don't think we want to go back as far as PGI versions from 2012, but supporting PGI 15.x makes sense, since it's probably still quite common?

@damianam You had a particular argument to use pgCC in combination with a particular MVAPICH2 build, right? That MVAPICH2 build can not be used with code that gets compiled with pgc++, did I get that right?

Feedback from PGI support:

Regarding the use of pgCC vs. pgc++ prior to 16.x, we recommend using pgc++
for versions after 14.10 and pgCC for version 14.10 and before.

I'll change the version check accordingly, and then this should be good to go?

@boegel the GDR versions of MVAPICH2 (http://mvapich.cse.ohio-state.edu/downloads/#mv2gdr) compiled with PGI used pgCC as compiler, so they don't work with pgc++. A similar problem happens with GCC also, due to the gfortran modules that are incompatible even between some minor versions (they compile with 4.6 I think, so 4.9.x doesn't work). However, the OSU guys have been very responsive and have no problem to provide versions compiled with whatever compiler you need.

Back to pgCC vs pgc++ maybe it makes sense to provide reasonable defaults (according to what PGI support said), but allow the installer to pick the compiler used by EB at toolchain installation time? Is that even possible?

@damianam well, sure, we can provide a custom toolchain option to force using pgCC rather than pgc++ for versions 14.10 and up...

toolchainopts = {'use_pgCC': True}

Does that make sense?

@boegel mmmh, that would imply changing it for every single easyconfig installed with that toolchain, wouldn't it? Or am I misunderstanding your suggestion?

@damianam well, yes... I'm not sure how else to handle this? Any suggestions?

EasyBuild framework unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/3026/console for more details).

This pull request is now ready for review/testing.

Please try and find someone who can tackle this; contact @boegel if you're not sure what to do.

Well, my idea would be to let the user choose at toolchain installation time which compiler will be used by the toolchain. That'd be more consistent than different toolchainopts in easyconfigs that use that toolchain, since you could potentially create incompatible binaries in the same toolchain (pgCC and pgc++ have different ABI).

However, the way I can think of to implement this is rather ugly/hackish: The toolchain module could define a variable used to choose one compiler or the other. Then the toolchain definition could set COMPILER_CXX to the value of that specifically defined variable (or default to pgc++).

I am not very happy with how it would look like, and honestly, for the amount of people that might run into this I think it makes sense to just forget about it.

@damianam I guess we could look into a generic override mechanism for toolchains, something like this: if $EASYBUILD_CXX is defined, let the toolchain mechanism define $CXX=$EASYBUILD_CXX`; if not, fall back to what the toolchain definition prescribes.

The same approach could be used for $CXXFLAGS, etc., and we can probably come up with a scheme where you can append things rather than blindly overwrite.

This could either by done via environment variables (i.e. either manually or through the environment module file for the toolchain), or maybe also via the EasyBuild configuration (--toolchain-overrides=CXX=pgCC:CXXFLAGS+=-foo).

But, since that's a generic feature, I don't think we should tackle it here, or block this PR over it.

Shall we open a separate issue on that, and get this one merged in?

Yes, seems like a sensible approach to me.

dedicated issue for the feature idea opened in #1760

Hence, this is good to go. Thanks for the feedback @damianam and @bartoldeman!