Todd, > We used to have separate packages for all the LLVM tools in Spack. I > actually did the initial packaging on that. Some of them have CMake > builds that can refer to an external LLVM install, and they’ll build > find as stand-alone tools linked with LLVM. I believe Clang even > built ok this way. AFAICT, though, not many of the clang developers > actually build this way, and support for standalone builds was pretty > spotty. We eventually switched to a model where Clang just has > variants for all the plugin tools. It’s been easier to maintain as a > monolithic thing, although I still think it’s kind of unwieldy for > the user.
Thanks for your insights. > I am not sure what to do about the module issues you mention below. > In Spack things can be compilers and dependencies, and we’re moving > towards making compilers more like regular dependencies. The module > issue below seems like an issue with EB’s toolchain/package > distinction. I don't think it is related to toolchains vs. dependencies. The question is more where to place packages/components in a module hierarchy with compiler modules that are marked as conflicting, such that only one of them can be loaded at a time. Markus > On 10/10/16, 7:42 AM, "[email protected] on behalf of Markus > Geimer" <[email protected] on behalf of > [email protected]> wrote: > > Hi folks, > > So far, I've always considered Clang to be a compiler. However, it > also comes with a bunch of libraries that can be used for writing > tools that need to do source-code parsing etc. Does anyone know > whether it is possible to just build the tooling libraries and later > direct a separate Clang compiler build to use those? > > Motivation: > In a hierarchical module naming scheme I would build Clang with > GCCcore. In the current EasyBuild scheme, the "real" compiler > module for it would then be ClangGCC, residing on the same level > as GCC (potentially both with a 'family("compiler")' in the > modulefile. This would allow loading the Clang module for other > software on the GCCcore level and also in other branches of the > hierarchy that may use the tooling libraries (e.g., Doxygen). > But in my particular case, I don't care about Fortran, i.e., Clang > would actually be the compiler module. Also, the current situation will > instantly change as soon as Clang itself comes with a Fortran > frontend (which is under development, afaik). Then ClangGCC would > disappear, the 'family("compiler")' would move into the Clang module, > and it couldn't be loaded for anything needing the tooling libraries > in GCCcore or any other branch of the hierarchy. > > Any ideas? Thoughts? > > Markus -- Dr. Markus Geimer Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49-2461-61-1773 Fax: +49-2461-61-6656 E-mail: [email protected] WWW: http://www.fz-juelich.de/jsc/ ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
