This is an archive of the discontinued LLVM Phabricator instance.

[bootstrap] Allow passing options to sub-builds for all targets
ClosedPublic

Authored by ldionne on Mar 16 2022, 9:39 AM.

Details

Summary

This patch makes it possible to pass a CMake option to one of the runtimes
for all targets being built by using RUNTIMES_<project>_<OPTION>. For
example, one can pass RUNTIMES_LIBCXX_TEST_CONFIG=<config> to the
bootstrapping build, and LIBCXX_TEST_CONFIG=<config> will be passed
to the runtimes sub-build as a result.

This is useful for customizing a sub-build for all targets. Note that
we could also simply allow passing through options without prefixing
them with RUNTIMES_ but this tries to be consistent with what already
exists for per-target passthroughs.

Diff Detail

Event Timeline

ldionne created this revision.Mar 16 2022, 9:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 16 2022, 9:39 AM
Herald added a subscriber: mgorny. · View Herald Transcript
ldionne requested review of this revision.Mar 16 2022, 9:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 16 2022, 9:39 AM

This is a strawman proposal. The end goal I'd like to achieve is being able to pass options to sub-builds without worrying about setting the right target. In other words, I want to pass roughly LIBCXX_TEST_CONFIG=<config> instead of having to do RUNTIMES_x86_64-apple-darwin20.xx.yy_LIBCXX_TEST_CONFIG=<config> for each target I'm building.

I don't mind how we achieve this, and if @phosek thinks this is not the right approach, I am not married to it.

phosek accepted this revision.Mar 17 2022, 4:40 PM

I like this!

This is useful for customizing a sub-build for all targets. Note that
we could also simply allow passing through options without prefixing
them with RUNTIMES_ but this tries to be consistent with what already
exists for per-target passthroughs.

I'd be fine with that, but in that case I'd prefer changing the per-target passthrough to be more consistent and the question is what would that look like.

What I could come up with is <project>_<option>_<target> or <project>_<target>_<option>, so LIBCXX_TEST_CONFIG_x86_64-linux-gnu=<config> or LIBCXX_x86_64-linux-gnu_TEST_CONFIG=<config> but there might be other ways.

llvm/runtimes/CMakeLists.txt
350–356

We should turn this into a function to avoid duplication but that can be done in a follow up change.

This revision is now accepted and ready to land.Mar 17 2022, 4:40 PM

What I could come up with is <project>_<option>_<target> or <project>_<target>_<option>, so LIBCXX_TEST_CONFIG_x86_64-linux-gnu=<config> or LIBCXX_x86_64-linux-gnu_TEST_CONFIG=<config> but there might be other ways.

Hmm, I think I like LIBCXX_TEST_CONFIG_x86_64-linux-gnu best. It is closest to what CMake already does for various options like CMAKE_<LANG>_FLAGS_<CONFIG> (e.g. CMAKE_CXX_FLAGS_Release).

In that case, I will amend this patch so it accepts options in the form LIBCXX_TEST_CONFIG as-is, and we can work on moving the per-target option passthrough to the new convention separately.

ldionne updated this revision to Diff 416497.Mar 18 2022, 7:12 AM

Allow passing e.g. LIBCXX_TEST_CONFIG directly.

Herald added a project: Restricted Project. · View Herald TranscriptMar 18 2022, 7:12 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
This revision now requires review to proceed.Mar 18 2022, 7:12 AM
ldionne updated this revision to Diff 416923.Mar 21 2022, 7:12 AM

Rebase onto main -- that should fix the bootstrapping CI failure.

ldionne accepted this revision as: Restricted Project.Mar 21 2022, 12:37 PM

I'm going to land this. What kind of migration story do you want for the per-target properties (which should be handled as a separate effort)?

This revision is now accepted and ready to land.Mar 21 2022, 12:37 PM
This revision was landed with ongoing or failed builds.Mar 21 2022, 12:38 PM
This revision was automatically updated to reflect the committed changes.

This actually broke our build. We pass LIBCXX_<option> to the default build on Darwin and RUNTIME_<target>_LIBCXX_<option> to the per-target build, but with this change, the LIBCXX_<option> now affects the per-target builds as well which is undesirable.

We need a way to pass options to Darwin builds. D117263 is an attempt at that but that change hasn't landed yet. Would it be fine with you if I reverted your change while we figure out a solution?

I'm going to land this. What kind of migration story do you want for the per-target properties (which should be handled as a separate effort)?

I'd like to use this opportunity to land D117263 so you can do LIBCXX_TEST_CONFIG_foo and not necessarily just LIBCXX_TEST_CONFIG_x86_64-linux-gnu. I'll update that change to support the new scheme.

We then need to decide if we want to continue supporting the current scheme RUNTIMES_<target>_<project>_<option> scheme. If not, then we need to start emitting a warning and mention that we'll deprecate that scheme in the next release.

gulfem added a subscriber: gulfem.Mar 21 2022, 6:49 PM

@phosek Thanks for reverting. Just to make sure I understand, you're going to roll this change into D117263 so I don't have anything to pick up?

@phosek Thanks for reverting. Just to make sure I understand, you're going to roll this change into D117263 so I don't have anything to pick up?

Yes that's the plan.