so, if I understand correctly, the problem is that the current behaviour results in

gjs.cc:34:76: warning: character constant too long for its type
   34 |  cout<<"                               This executable is compiled with "<<GC_DEFAULT_PLATFORM<<" as default"<<endl<<endl;
      |                                                                            ^~~~~~~~~~~~~~~~~~~
gjs.cc:165:13: warning: character constant too long for its type
  165 |    platform=GC_DEFAULT_PLATFORM;
      |             ^~~~~~~~~~~~~~~~~~~
gjs.cc:166:45: warning: character constant too long for its type
  166 |    if(verb>1)cout<<"Information : using  "<<GC_DEFAULT_PLATFORM<<" as default cluster platform!"<<endl;
      |                                             ^~~~~~~~~~~~~~~~~~~
gjs.cc: In function int main(int, char**):
<command-line>: warning: overflow in conversion from int to char changes value from 1850753619 to 'S' [-Woverflow]
gjs.cc:165:13: note: in expansion of macro GC_DEFAULT_PLATFORM
  165 |    platform=GC_DEFAULT_PLATFORM;
      |             ^~~~~~~~~~~~~~~~~~~

and running gjs shows This executable is compiled with 1850753619 as default

This PR gets rid of the warning and running gjs shows This executable is compiled with openPBS as default

Maybe we should additionally check the output of gjs in sanity_check_commands to always make sure that the default platform is the intended one?

Yes, that's exactly the problem. In my case, warnings were actual errors and thus, the build was constantly failing.
I think that the sanity check for gjs should be implemented in the easyblock since it already has default_platform defined. Don't know, will something like this work?

def sanity_check_step(self):
    ...
    custom_commands = ["gjs -h | grep %s" % self.cfg['default_platform']]
    super(EB_GATE, self).sanity_check_step(custom_paths=custom_paths, custom_commands=custom_commands)

Don't know, will something like this work?

def sanity_check_step(self):
    ...
    custom_commands = ["gjs -h | grep %s" % self.cfg['default_platform']]
    super(EB_GATE, self).sanity_check_step(custom_paths=custom_paths, custom_commands=custom_commands)

This seems to work:

== 2022-01-06 13:44:06,693 easyblock.py:3387 INFO sanity check command gjs -h | grep openPBS ran successfully!  (output:                                openmosix - condor - openPBS - xgrid
                               This executable is compiled with openPBS as default
  -openPBSscript, os         : template for an openPBS script
                               see the example that comes with the source code (script/openPBS.script)
  GC_PBS_SCRIPT : the openPBS template script (!optionnal variable!)
    gjs -numberofsplits 10 -clusterplatform openPBS -openPBSscript /somedir/script macro.mac
)

but I'm not sure if easybuild will consider an empty stdout as an error in this case

but I'm not sure if easybuild will consider an empty stdout as an error in this case

grep returns a non-zero error code when there is no match and the sanity check will fail in that case, so that's fine, but you'd need to grep for something like openPBS as default, because openPBS appears elsewhere in the output even when GC_DEFAULT_PLATFORM isn't correctly defined

(which probably means it's falling back to openPBS anyway, but even if that's the case, this PR still makes sense to me)

oh, yes, you are right. I've changed the string to This executable is compiled with %s as default.

Test report by @migueldiascosta

Overview of tested easyconfigs (in order)

• SUCCESS GATE-9.0-foss-2019b-Python-3.7.4.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
c2dhpc - Linux centos linux 7.6.1810, x86_64, AMD EPYC 7601 32-Core Processor (zen), Python 2.7.5
See https://gist.github.com/ee73e3e49b5cd0b1ca8a716084f0e9b0 for a full test report.

test report for GATE-8.2-foss-2021a.eb at easybuilders/easybuild-easyconfigs#14663 (comment)

lgtm

@boegel if you think it's worth it, can you submit a test report for the older GATE easyconfigs? I'm not being able to because of problems building a dependency (ROOT) for those older toolchains, but that's a separate issue (and I'm assuming you already have those installed)

Test report by @boegel

Overview of tested easyconfigs (in order)

• SUCCESS GATE-6.2-intel-2016a-Python-2.7.11.eb
• SUCCESS GATE-7.1-intel-2016a-Python-2.7.11.eb
• SUCCESS GATE-7.2-intel-2016a-Python-2.7.11.eb
• SUCCESS GATE-8.0-foss-2017b-Python-2.7.14.eb
• SUCCESS GATE-8.0-intel-2017b-Python-2.7.14-Geant4-10.04.eb
• SUCCESS GATE-8.0-intel-2017b-Python-2.7.14.eb
• SUCCESS GATE-8.1.p01-foss-2018b-Python-2.7.15.eb
• SUCCESS GATE-8.2-foss-2017b-Python-2.7.14.eb
• SUCCESS GATE-8.2-foss-2018b-Python-2.7.15.eb
• SUCCESS GATE-8.2-intel-2017b-Python-2.7.14.eb
• SUCCESS GATE-9.0-foss-2019b-Python-3.7.4.eb

Build succeeded for 11 out of 11 (11 easyconfigs in total)
node2602.swalot.os - Linux centos linux 7.9.2009, x86_64, Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz (haswell), Python 3.6.8
See https://gist.github.com/653c24b5c29a99b7f5276998802c1d19 for a full test report.