Maik, I double Jack's explanation on why QT5 is built at the highest toolchain level. Similarly in our stack we moved Python to the GCC/iccifort level by removing the packages that depend on MPI/FFTW and install Qt5 with the GCC/iccofort toolchains. Moving Python to a lower toolchain in the official easyconfig repo is something that we have been discussing for a while and we are making steps in that directions. In the meantime nothing stops you to do are we and Jack did.
As for CUDA, the use of toolchains like `fosscuda` and `intelcuda` allow to avoid the need of adding version suffixes for MPI and all other software built with CUDA support. In our case we prefer to avoid version suffixes as much as we can since they introduce unnecessary complication for our users. Obviously this is possible only if you are using hierarchical modules. -- Davide Vanzo, PhD Application Developer Adjunct Assistant Professor of Chemical and Biomolecular Engineering Advanced Computing Center for Research and Education (ACCRE) Vanderbilt University - Hill Center 201 (615)-875-9137 www.vanderbilt.edu/accre On 2018-06-20 10:19:58-05:00 [email protected] wrote: [oops.... meant to send to the list] -------- Forwarded Message -------- Subject: Re: [easybuild] Minimal vs full toolchain, Qt, CUDA etc. Date: Wed, 20 Jun 2018 09:56:06 -0500 From: Jack Perdue <[email protected]> To: Maik Schmidt <[email protected]> Howdy Maik, Here we use a stripped down Python as a builddependency to build:   Qt5-5.10.1-GCCcore-6.4.0-Python-2.7.14-bare.eb and   Qt5-5.10.1-GCCcore-6.4.0-Python-3.6.3-bare.eb By default, the full Python needs MPI/maths (for numpy) so if you build Qt with the regular Python you have to promote the toolchain.  Python-bare just provides the basics. Works fairly well. There are other initiatives in EB to clean this up using Python-core and the like.  But this is what we've been using for now. As for CUDA.... I wondered the same.... the answer was that OpenMPI has hooks for CUDA so if you include CUDA early in the toolchain (while building OpenMPI) then you get some MPI-enabled CUDA.  I/we haven't much experience with that yet (curious to see what TensorFlow can do) but that's the reasoning for that (though I do wish it was easier like you suggest) As ever, there are examples at:   https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.siliconslick.com%2Feasybuild%2Feasyconfigs%2F&data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C969e7c72f65249da661e08d5d6c145e8%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C636651047945281105&sdata=uZgbznCATjG8G%2BC6o5Pxkvz1UtS2qIJ8NiLSqYVn9Ys%3D&reserved=0 See ada and terra. Jack Perdue Lead Systems Administrator High Performance Research Computing TAMU Division of Research [email protected] https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhprc.tamu.edu&data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C969e7c72f65249da661e08d5d6c145e8%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C636651047945281105&sdata=7DXnIKRWuF6BXcxiI1YSxFxdv7M8W8Gdb116krNrxUQ%3D&reserved=0 HPRC Helpdesk: [email protected] On 06/20/2018 09:21 AM, Maik Schmidt wrote: > Hi, I've been asked by one of our users why Qt5 is built with the full > toolchain (foss or intel) even though it does not really use MPI or > MKL for that matter. I've looked at the dependencies of Qt itself and > apparently he is correct, why is this not GCCcore? There's no reason > to use the full toolchain here, right? > > On another note, what has been the reasoning behind introducing an > entire new toolchain only to add CUDA? it really makes not much sense > to me, because then I have to build a lot of duplicate software that > doesn't even need CUDA just to support this toolchain (foss vs > fosscuda)... e.g. why would I need a HDF5 -fosscuda if it is exactly > the same as the -foss version? > > The solution with just adding a versionsuffix and CUDA as a dependency > to software requiring it seemed much cleaner to me, but maybe I'm > missing something here... > > Thanks for your input, > > Maik > </[email protected]></[email protected]>
