New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Windows] Support --features=compiler_param_file #35
Comments
Hello again, @LoSealL! Good to see you back :) I'd love to understand a little more about what you're trying to solve with this. I think that's a Windows-specific bazel flag for command lines that are too long. Is that right? [In my head, I'm imagining that we probably wouldn't need to work around command-line-length limits for clangd, right, since presumably clangd can read arbitrary length commands out of the compile_commands.json file--and we'd like everything self contained in that file?] All the best, |
Yes, this is the Windows-specific flag in Bazel, while it's also a recommended flag in Bazel's official document. So I think many people using Bazel on Windows would specify this flag (including me). It doesn't affect clangd itself, but while parsing sources and headers in the python script, it will fail to read the true parameters because it only gets a parameter file, such as:
So we need a patch to handle it, basicly to read the actual parameters in the file for later parsing. Thanks. |
Oh I see. (Same link, right?) Is the issue is just for header finding, then? I'm mostly Linux/mac focused at the moment, as you probably know. So I'll need a bit of your help here. Do you know if the max command length also exists for subprocess calls from Python? I'm trying to scope whether it would it work to have this tool just (automatically) turn off that feature--or whether it'll be important to keep it on. |
Windows compatibility hopefully landing soon. It's a bit stalled out because some things need to be a bit more robust before it lands IMO. |
I really appreciate your care and willingness to help @LoSealL. We'll definitely need to land #28 and then return to this. (I'm going to try to provision a Windows machine tomorrow.) But in the meantime, do you know how we'd fix this? Same question as above: Could sidestep the issue by having the tool disable --features=compiler_param_file when running aquery? Or is it clear to you that we need to read (and write!) these files? |
Yes, I know how to fix it, along with the locale problem. I am using a customized python script in my own project and testing it for several weeks, current fixes list below:
|
Awesome! |
Only non-awesome is that it looks like we duplicated some work bc I didn't know you'd done all that and we were slow on getting that branch merged. But could be worse! Multiple great people arriving at the same conclusions :) Could I ask you to look at the latest and see what you can improve? |
With these param files: I was just handling some cases for people where no build had yet been run since the last clean, so generated files were missing. Could I ask you to check those cases with params files? |
More generally, thank you in advance! Sorry this has been slow and somewhat frustrating, but please know that I really appreciate your efforts. You might also chuckle knowing that last night I set my visual studio to Chinese (which I do not read!) to test things :) |
I found that most issues are resolved in the latest patch, great! @cpsauer
I will try to fix these on my own fork first, and make a new PR when it's ready |
Thanks so much for investigating, @LoSealL! I think let's not worry about the first two. I'm more interested in the third bullet, where we're trying to generate a good and useful compile_commands.json, even when the code can't be compiled. I think it's fairly common that, during development, the code will be broken sometimes, so we don't want to require it to compile. We can definitely get useful commands with the compiler_param_file feature off, at least. Thanks again! P.S. I'm curious what motivated the append feature! |
Hey, @LoSealL! Just wanted to touch base to see how things are going. Cheers, |
Thanks for posting, @LoSealL! I've read through your code. Did you get a chance to try having the tool get the full, updated arguments without requiring a build by having the tool temporarily disable [Sorry about the whitespace issues that have crept in. Thanks for dealing with those. If you know of a good, e.g. bot to deal with them, I'd love to hear about it.] |
A good point, will have a try. Windows has a command line buffer limitation, some targets with huge source files and compile flags will be broken, but not sure how they behave under |
But since aquery doesn't actually run the command, won't we be okay? |
[Though we might well hit the limit while invoking msvc to find headers. Assuming that's a problem, we could just write our own tmp command file, right, and still not require that the code build?] |
@cpsauer Have a quick try, seems to work! Let me look into how to do it. |
Yay! Thanks @LoSealL. [One thing to keep in mind: if writing tmp files to find headers, we'll need to make sure the threads write to different files to avoid collisions.] |
@LoSealL, just wanted to check in: Where are we at on this? Thanks! |
I was just reading though :) Thanks. (Github notified me when you pushed a new commit.) Let's continue the discussion over there. I'll reply there in a sec. |
Build using
--features=compiler_param_file
would wrap all source files and flags into a.params
file, I think we should support to read from the.params
file instead of reading from command line directly.The text was updated successfully, but these errors were encountered: