Markus,
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.
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.
-Todd
On 10/10/16, 7:42 AM, "easybuild-requ...@lists.ugent.be on behalf of Markus
Geimer" <easybuild-requ...@lists.ugent.be on behalf of m.gei...@fz-juelich.de>
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: m.gei...@fz-juelich.de
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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
