Skip to content

Compiler shards represented as HostBuildDependency objects #1004

Open
@staticfloat

Description

@staticfloat

What if we went totally crazy and represented things like Glibc_jll, GCC_jll, LLVM_jll, etc… all as HostBuildDependencies and choose_shards() just gave a bunch of special HostBuildDependency objects back? We’d of course need to customize things a bit (we might want to have finer control over where these things get unpacked, and we’d have to integrate it into generate_compiler_wrappers()) but I can see a few advantages:

  • unification of setup: right now we have so many different ways of bringing things into the build environment: Dependency(), apk add, compilers=[:c, :rust] and now HostBuildDependency(). We could conceivably get rid of lots of these things by unifying everything behind HostBuildDependency().

  • Build manifests. I want to embed a .toml file that contains every piece that was used to build a JLL. Explicitly declaring what JLLs were used as the build tools would make this really granular.

  • Really easy testing of new toolchains. Trying out a new compiler version could be as easy as just overriding the default version that BBB adds to your set with something else. I’m not sure what the API here should be, but I’m thinking something like:

dependencies = Dependency[
    CompilerSet([:c, :rust])...,
    # The rest of your compilers
]

We can have backwards-compatibility and add the C compilers by default if no HostBuildDependencies are specified.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions