-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[CMake] Generate a usable compile_commands.json #16718
[CMake] Generate a usable compile_commands.json #16718
Conversation
d3d2671
to
0f0aa58
Compare
EWS run on previous version of this PR (hash 0f0aa58)
|
0f0aa58
to
6ba926a
Compare
EWS run on previous version of this PR (hash 6ba926a)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a --help argument, even though the script is probably not intended to be called manually. Somebody else will thank you for it a few years from now....
help is automatically added by argparse. Iβll fix the windows failure though. |
6ba926a
to
9463525
Compare
EWS run on current version of this PR (hash 9463525)
|
https://bugs.webkit.org/show_bug.cgi?id=260218 Reviewed by Michael Catanzaro. When using unified builds CMake generates a compile_commands.json that isn't useful by many tools as it lacks much of the sources. This adds a script to expand UnifiedSources into the full list of sources. It outputs it to webkit_compile_commands.json. * Source/cmake/WebKitCommon.cmake: * Tools/Scripts/rewrite-compile-commands: Added. Canonical link: https://commits.webkit.org/266947@main
9463525
to
5c9dd47
Compare
Committed 266947@main (5c9dd47): https://commits.webkit.org/266947@main Reviewed commits have been landed. Closing PR #16718 and removing active labels. |
I can't find out how to specify a custom file to clangd, seems like it really expects a file named |
Yes I think this would be a good idea as I've hit other tools being hardcoded as well. |
}) | ||
break | ||
else: | ||
print('Failed to find', include_path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This triggers for many files here, *MessageReceiver.cpp
that don't exist and files from WebCore/DerivedSources/
mostly.
Is this OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm in my local builds it found everything. What was your specific build config (and which commit maybe)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also was it ran after everything was built? You can run ninja webkit_compile_commands.json
after a build to run it last.
We are kinda in a weird situation where this script technically depends on every generated source, maybe we could somehow actually collect that list, but I don't know a simple solution... So maybe it runs out of order sometimes.
I didn't want to rely on checking for files existing but the rules of where a file ends up didn't have a clear pattern, but maybe some static mapping is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just doing a clean GTK Debug build triggers the issue here, with sccache enabled, (edit: with ASan enabled too) the script runs early on, I suppose before the MessageReceiver.cpp files have been generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually those MessageReceiver.cpp files are for features we don't enable, such as GPUProcess, so it's expected that they shouldn't exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually those MessageReceiver.cpp files are for features we don't enable, such as GPUProcess, so it's expected that they shouldn't exist.
The file has to exist in some include path, it is compiled, otherwise the build would fail.
5c9dd47
9463525
π§ͺ wpe-wk2