Skip to content

build: Notify when no pre-built archive is available for the target#1945

Open
TheJanzap wants to merge 5 commits intodenoland:mainfrom
TheJanzap:notify-when-no-prebuild
Open

build: Notify when no pre-built archive is available for the target#1945
TheJanzap wants to merge 5 commits intodenoland:mainfrom
TheJanzap:notify-when-no-prebuild

Conversation

@TheJanzap
Copy link
Copy Markdown

@TheJanzap TheJanzap commented Mar 25, 2026

This PR adds a panic into build.rs when a v8 build is started with a target that v8 does not provide a pre-built archive for and RUSTY_V8_MIRROR is unset (i.e. the script downloads the archive from this GitHub repo). In this case, the panic message advises to rebuild v8 with V8_FROM_SOURCE=1.

I currently use a hardcoded list of targets for this, but if you have a better solution, please suggest so :)

I am also a bit unsure if the placement of the code is appropriate, as the build script is quite expansive, so feel free to also suggest improvements there.

Implements the feature discussed in #1877

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Mar 25, 2026

CLA assistant check
All committers have signed the CLA.

Copy link
Copy Markdown
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review

The idea is good — failing early with a clear message is much better than a confusing 404. But the implementation has several issues:

Bug: The target list is wrong

The PR's PREBUILT_TARGETS list has "aarch64-unknown-linux", but the actual Rust target triple (and the release asset name) is "aarch64-unknown-linux-gnu". This means is_target_prebuilt would return false for aarch64 Linux, incorrectly panicking on one of the most common targets.

Bug: Windows targets lack debug prebuilts

The Windows targets (aarch64-pc-windows-msvc, x86_64-pc-windows-msvc) only have release prebuilts in the actual GitHub releases. A debug build targeting Windows would pass the is_target_prebuilt check but still 404. The check doesn't account for profile.

Design concern: Hardcoded list is fragile

The list will drift as targets are added/removed. An alternative approach: catch the 404 from the download and provide the helpful error message with the V8_FROM_SOURCE=1 suggestion at that point. This would be self-maintaining and always accurate.

Minor: RUSTY_V8_MIRROR detection

The check base == default_base is an indirect proxy for "RUSTY_V8_MIRROR is unset." A cleaner approach would be env::var("RUSTY_V8_MIRROR").is_err().

Summary

The aarch64-unknown-linux typo is a blocker — it would break aarch64 Linux builds. The missing debug/release distinction for Windows is a secondary concern. I'd suggest either:

  1. Fix the list and add a profile check, or
  2. (Better) Replace the hardcoded list with a 404-triggered error message in the download logic

@TheJanzap
Copy link
Copy Markdown
Author

TheJanzap commented Mar 26, 2026

I also briefly considered checking for the 404, but IMO the current approach is simpler.

The download is triggered by Deno, Python and curl. The clean way would be to check each one for the 404, but since they are launched as external processes, we only get the exit codes. Depending on the program, there may or may not be a specific exit code for a 404 we can check for. I wager the code for this could get exhaustive and messy.

I've fixed the other problems you mentioned in your review, but if you really want, I can try implement exit-code checks.

@TheJanzap TheJanzap requested a review from bartlomieju March 27, 2026 05:27
@Xeonacid
Copy link
Copy Markdown

How about fallback to bulld from source unconditionally when prebuilt download fails?

@TheJanzap
Copy link
Copy Markdown
Author

How about fallback to bulld from source unconditionally when prebuilt download fails?

Not sure how I feel about this. Currently, we explicitly tell the user that they have to build from source, and by setting the env var they acknowledge this. If we simply fall back to a source build, the user might have no idea that this is happening and wonder why their build is taking so long (especially if v8 is a (in)direct dependency).

Yes, there will probably be a line in the log telling the user this, but I think hardly anyone will spot the message, as it'll probably be surrounded by a ton of other log messages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants