> 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.


> On 10/10/16, 7:42 AM, " on behalf of Markus 
> Geimer" < on behalf of 
>> 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

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

Reply via email to