(low priority) DEFAULT_CPP_COMPILER in make_opts vs $CXX environment variable

[valassi]

Hi @oliviermattelaer there is inconsistency between what make_opts does and what cudacpp does

• make_opts hardcodes a compiler DEFAULT_CPP_COMPILER=g++
• cudacpp relies on the CXX environment variable

Personally I think that the choice of compiler should be left to environment variable, it should not be hardcoded in a makefile fragment. Otherwise having parallel builds for, say, g++ and clang becomes a nightmare, you need to change makefiles all the time.

I have been using this to do the port to clang, icx and other compilers.

So my question/suggestion is: can make_opts be modified so that DEFAULT_CPP_COMPILER only kicks in if CXX is not already set?

(I am asking now because I just happened to see that the LUMI build for AMD GPUs etc uses a weird mix of g++ and CC, while it should be using CC everywhere... the problem is there since a long time but I had not observed it before, and I now have weird build issues that I nee dto debug on LUMI)

Thanks
Andrea

[oliviermattelaer]

In Holliday, so will not discuss it in detail. But short answer is no. This will change the full mg5 setup, so this can only be done for version 4. So forget about it. Sent from Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Andrea Valassi ***@***.***> Sent: Monday, July 22, 2024 12:01:31 PM To: madgraph5/madgraph4gpu ***@***.***> Cc: Olivier Mattelaer ***@***.***>; Assign ***@***.***> Subject: Re: [madgraph5/madgraph4gpu] DEFAULT_CPP_COMPILER in make_opts vs $CXX environment variable (Issue #932) Assigned #932<#932> to @oliviermattelaer<https://github.com/oliviermattelaer>. — Reply to this email directly, view it on GitHub<#932 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH6535SQFWHK2SR52JOAKEDZNTJ7XAVCNFSM6AAAAABLH7FAJGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGU4TQNZXG4ZTSNY>. You are receiving this because you were assigned.Message ID: ***@***.***>

[valassi]

Hi Olivier, thanks.
(Sorry to bug you on holiday, you can reply when you come back next week).

Ok I understand. What I would do then is to change the souce code only in the generated code in the madgraph4gpu repo, through the generateAndCompare.sh script. This would have no effect on user use cases through launch (it would not go in patchMad.sh). It looked like I am the only one using the generated code in the madgraph4gpu repo anyway, so I hope this is ok. Let me know otherwise.

Otherwise it simply becomes next to impossible for me to test and provide support for other compilers or even LUMI/AMD.

Anyway we can discuss next week.

Thanks
Andrea

[valassi]

Otherwise it simply becomes next to impossible for me to test and provide support for other compilers or even LUMI/AMD.

Apologies, I correct myself. I thought that this was one of the issues causing build errors #933, but I think it is unrelated. So it is definitely low priority. Rephrasing: I still manage to do useful tests on LUMI/AMD without faddressing this issue. But it would be useful to discuss it at some point because the build environment does seem inconsistent now on LUMI for instance (and so I have no idea also if the physics that comes out is really trustable).