Very exciting!

For maintaining Aro, I think we should pick one of these options:

• Put Aro in src/, don't mark it as vendored, allow tight coupling with other compiler code, and periodically port code back and forth between the Zig source tree and the Aro source tree. This is @kubkon's current strategy for zld.
• Start maintaining Aro in the zig source tree itself; archive the external Aro project.
• Merge Support relative paths in package manager #14603, continue maintaining Aro separately, use deps/, mark the files as vendored, have a policy of no downstream patches, and use Aro via @import("aro") using the public Aro API only.

Up to you, @Vexu. What do you prefer?

I was planning on going with option 3.

Sounds great 👍

So, what's the transition plan? For now, enable it only when -Denable-llvm=false?

That's what it does currently:

// Make a decision on whether to use Clang or Aro for translate-c and compiling C files.
const c_frontend = blk: {
    if (!build_options.have_llvm) break :blk .aro;
    if (options.c_frontend) |explicit| break :blk explicit;
    break :blk .clang;
};

Not sure what the CI failure is caused by. I can't reproduce it locally with zig build.

I believe the CI failure is because zig2 doesn't have any of the package management code included in it, including path-based dependencies (

Yes I'm sorry, after I mentioned #14603 above, I realized it wasn't actually going to work exactly that way because we want to avoid all that machinery while bootstrapping. I think it will be fine just adding logic to build.zig instead for integration. I think you had it that way in the first place anyway.