allow setting optarch compiler flags in the easyconfig#2595
allow setting optarch compiler flags in the easyconfig#2595boegel merged 7 commits intoeasybuilders:developfrom
Conversation
|
@migueldiascosta That's a good point, but on the other hand it would be weird to specify flags specific to a compiler different from the toolchain compiler in the easyconfig file... It's nice to support this for flexibility, but this should really only be used by exception I think, of for site customization reasons. And @damianam Thoughts on this? |
|
IMO if this doesn't break anything it can go in. I agree that supporting the per-compiler syntax is weird in easyconfigs. It will break |
|
I'd love to see a test for this before merging it in... Up for that @migueldiascosta? See |
|
but I probably should have used a different toolchain for the new test easyconfigs... |
|
@migueldiascosta Is this still Don't worry too much about which toolchains were used in the test easyconfigs, I'm working on a big cleanup there anyway because of impending deprecation of the |
… than adding two new test easyconfigs with just a different value for toolchainopts
| res = [os.path.basename(x) for x in find_related_easyconfigs(test_easyconfigs, ec)] | ||
| self.assertEqual(res, ['toy-0.0-gompi-1.3.12-test.eb', 'toy-0.0-gompi-1.3.12.eb']) | ||
| self.assertEqual(res, ['toy-0.0-gompi-1.3.12-optarch-map.eb', 'toy-0.0-gompi-1.3.12-optarch.eb', | ||
| 'toy-0.0-gompi-1.3.12-test.eb', 'toy-0.0-gompi-1.3.12.eb']) |
There was a problem hiding this comment.
@migueldiascosta I would like to avoid adding additional test easyconfigs if we can avoid it, alternate approach implemented in migueldiascosta#5
tweak existing toy easyconfig in test_easyconfig_optarch_flags rather than adding two new test easyconfigs with just a different value for toolchainopts
|
Thanks @migueldiascosta! |
If
toolchainopts[optarch]from the easyconfig is a string, use that as architecture optimization flags instead ofbuild_options('optarch')One problem with this approach is that the per-compiler syntax is not supported, unlike
build_option('optarch')(which has been parsed earlier, intools.options._postprocess_optarch)Using only compiler-specific flags in the easyconfig optarch would not usually be an issue, since the compiler is already set by the easyconfig and this is meant for very specific cases, but I suppose it will break
--try-toolchain...Should we also postprocess optarch here? (or is there a better way?)