pkg: embed windows manifest to support long file paths if enabled #2049

thargor · 2021-11-04T12:28:29Z

fixes #364

Implementation is based on https://gal.hagever.com/posts/windows-long-paths-in-rust/ .

This still requires long file paths to be enabled in the windows registry.

…system

thargor · 2021-11-04T12:35:18Z

this is also what https://github.com/nabijaczleweli/cargo-update is using

SimplyDanny · 2021-11-18T17:53:46Z

Works fine for me with the registry key LongPathsEnabled set to 1.

SimplyDanny · 2021-11-18T18:04:57Z

build.rs

 use app::{RGArg, RGArgKind};
+extern crate embed_resource;


This line is no longer needed since Rust Edition 2018.

Indeed, this should be removed.

SimplyDanny · 2021-11-18T18:06:51Z

build.rs

@@ -48,6 +48,9 @@ fn main() {
    if let Some(rev) = git_revision_hash() {
        println!("cargo:rustc-env=RIPGREP_BUILD_GIT_HASH={}", rev);
    }
+
+    // embed windows application manifest file


From what I see browsing through the code base, comments are written as sentences, i.e. they start with a capital letter and end with a period.

Yeah, that's preferred. But what would be better here is more elaboration. Mostly, this comment nearly repeats what the code itself says, without adding much. I think this comment should:

Say why this is being done.

Include instruction on how to take advantage of it. If you're someone who is reading this build.rs trying to understand it, and we say, "this enables long file paths" without saying that it also requires a registry edit, that might produce some confusion. So let's shine a light where we can.

BurntSushi

I got through most of this PR review before realizing that it's using a dependency that I will not bring in. I'm sorry. Someone tried this before in #1898. Specifically, see my comment on that PR.

BurntSushi · 2021-11-18T18:35:41Z

build.rs

@@ -1,12 +1,12 @@
+use clap::Shell;


Why was this moved? Please put it back. :)

BurntSushi · 2021-11-18T18:35:50Z

build.rs

 use app::{RGArg, RGArgKind};
+extern crate embed_resource;


Indeed, this should be removed.

BurntSushi · 2021-11-18T18:37:46Z

build.rs

@@ -48,6 +48,9 @@ fn main() {
    if let Some(rev) = git_revision_hash() {
        println!("cargo:rustc-env=RIPGREP_BUILD_GIT_HASH={}", rev);
    }
+
+    // embed windows application manifest file


Yeah, that's preferred. But what would be better here is more elaboration. Mostly, this comment nearly repeats what the code itself says, without adding much. I think this comment should:

Say why this is being done.

Include instruction on how to take advantage of it. If you're someone who is reading this build.rs trying to understand it, and we say, "this enables long file paths" without saying that it also requires a registry edit, that might produce some confusion. So let's shine a light where we can.

BurntSushi · 2021-11-18T18:38:53Z

rg-manifest.rc

@@ -0,0 +1,2 @@
+#define RT_MANIFEST 24
+1 RT_MANIFEST "rg.exe.manifest"


I can't comment on it, but where did the rg.exe.manifest file come from? How was it generated?

Also, I think it would be better to put these files into a windows sub-directory, instead of polluting the root of the repo even more than it is.

Oh I see, GitHub falsely detects it as a binary file, but it's just plain text. Phew. That's good. Yeah, I think just move these into a new windows sub-directory. Thanks!

BurntSushi · 2021-11-18T18:42:18Z

build.rs

@@ -48,6 +48,9 @@ fn main() {
    if let Some(rev) = git_revision_hash() {
        println!("cargo:rustc-env=RIPGREP_BUILD_GIT_HASH={}", rev);
    }
+
+    // embed windows application manifest file
+    embed_resource::compile("rg-manifest.rc");


What does this do on non-Windows targets? Even if nothing, it might be nice to gate this on #[cfg(windows)] to make it a bit clearer to those reading the code.

BurntSushi · 2021-11-18T18:43:09Z

Cargo.toml

@@ -61,6 +61,7 @@ version = "0.3.0"

 [build-dependencies]
 lazy_static = "1.1.0"
+embed-resource = "1.6"


I don't think this is needed for non-Windows builds right? Could you please make this a target specific dependency for windows only? Thanks!

thargor · 2021-11-18T21:47:24Z

@BurntSushi @SimplyDanny thank you for your feedback!

Would an implementation based on https://crates.io/crates/windres (which is based on https://crates.io/crates/find-winsdk ) be acceptable for ripgrep?

BurntSushi · 2021-11-18T21:52:03Z

As long as there's nothing written by Jonathan Blow in the dependency tree, the licenses are compatible and the crates are decently maintained. Remember, once this gets added to ripgrep, it's forever mine to maintain, evev if the dependencies go defunct.

So in short: probably, but I'll still need to do a review if a PR comes in.

t-rapp · 2022-06-09T13:58:20Z

For anyone interested in long path support: Stumbled over this recent pull request for rustc which adds a similar manifest file to the rustc executable. It apparently works for the *-msvc target by using a build script without external libraries.

Previously, the parsing was more limited and couldn't handle sub-paths in repos, like BurntSushi/ripgrep#2049. Now anything that includes an org/user & repo at the beginning of the path should work.

BurntSushi · 2023-07-08T14:27:50Z

@ChrisDenton what are your thoughts on this PR? Is this the right way to support long paths on Windows?

ChrisDenton · 2023-07-08T15:17:36Z

Yep. I'd be minded to append .xml to the file name to make github happy. And while an xml declaration (<?xml ...) isn't strictly necessary, it can make other tools happy. Also linking to the docs would make sense.

My only quibble is that it's a lot of dependencies for what can be a couple of lines in a build script (plus a few more lines to apply it conditionally). Though unfortunately windows-gnu does not support this.

BurntSushi · 2023-07-08T17:14:44Z

@ChrisDenton Oh yessss! Thank you for that link. I will do what you did for rustc. That looks much better.

See the README and comments in the build.rs. Basically, this embeds an XML file that I guess is a way of setting configuration knobs on Windows. One of those knobs is enabling long path support. You still need to enable it in your registry (lol), but this will handle the other half of it. Fixes #364, Closes #2049

pkg: embed windows manifest to support long file paths if enabled on …

ddd0df9

…system

thargor mentioned this pull request Nov 4, 2021

long file name support by default? #364

Closed

SimplyDanny reviewed Nov 18, 2021

View reviewed changes

BurntSushi requested changes Nov 18, 2021

View reviewed changes

BurntSushi closed this Nov 18, 2021

BurntSushi reopened this Nov 18, 2021

thargor marked this pull request as draft November 18, 2021 22:05

mitchcapper mentioned this pull request Oct 16, 2022

ci: Added uploading build artifacts and also build release #2332

Closed

BurntSushi added the rollup A PR that has been merged with many others in a rollup. label Jul 8, 2023

BurntSushi closed this in db6bb21 Jul 8, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

pkg: embed windows manifest to support long file paths if enabled #2049

pkg: embed windows manifest to support long file paths if enabled #2049

thargor commented Nov 4, 2021

thargor commented Nov 4, 2021

SimplyDanny commented Nov 18, 2021

SimplyDanny Nov 18, 2021

BurntSushi Nov 18, 2021

SimplyDanny Nov 18, 2021

BurntSushi Nov 18, 2021

BurntSushi left a comment

BurntSushi Nov 18, 2021

BurntSushi Nov 18, 2021

BurntSushi Nov 18, 2021

BurntSushi Nov 18, 2021

BurntSushi Nov 18, 2021

BurntSushi Nov 18, 2021

BurntSushi Nov 18, 2021

thargor commented Nov 18, 2021

BurntSushi commented Nov 18, 2021

t-rapp commented Jun 9, 2022

BurntSushi commented Jul 8, 2023

ChrisDenton commented Jul 8, 2023

BurntSushi commented Jul 8, 2023

		@@ -0,0 +1,2 @@
		#define RT_MANIFEST 24
		1 RT_MANIFEST "rg.exe.manifest"

pkg: embed windows manifest to support long file paths if enabled #2049

pkg: embed windows manifest to support long file paths if enabled #2049

Conversation

thargor commented Nov 4, 2021

thargor commented Nov 4, 2021

SimplyDanny commented Nov 18, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BurntSushi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thargor commented Nov 18, 2021

BurntSushi commented Nov 18, 2021

t-rapp commented Jun 9, 2022

BurntSushi commented Jul 8, 2023

ChrisDenton commented Jul 8, 2023

BurntSushi commented Jul 8, 2023