Skip to content

[cmake] Don't generate per-file "__SHORT_FILE__" defines on visual studio builds #151167

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

Merged
merged 2 commits into from
Jul 30, 2025

Conversation

RKSimon
Copy link
Collaborator

@RKSimon RKSimon commented Jul 29, 2025

As reported on #150677 - this is preventing msbuild parallelization as cmake is repeatedly being updated

@RKSimon RKSimon requested review from jpienaar and joker-eph July 29, 2025 15:01
@llvmbot llvmbot added the cmake Build system in general and CMake in particular label Jul 29, 2025
endif()
endforeach()

# Don't generate __SHORT_FILE__ on MSVC builds as it can force repeated cache regeneration.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you provide more info on the "repeated cache generation" aspect? You mentioned before that the build would come to a halt which seems a bit different than a cache problem?
At least link to the discussion on the original PR maybe?

It's not clear to me that someone reading this right now would even connect the dots to MSBuild-specific issue.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't know enough about how cmake does its thing on visual studio - is it possible it gets run multiple times or something during the build? All I know is #150677 slowed everything to a crawl.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I mean you refer to a "cache", which cache? In general I think of "ccache" when I read this. If you mean that this triggers repeated cmake invocation, then why not write it as is?
You likely should be able to see which process is churning why things seem slow? If cmake is re-running that should be visible, and there should be no compilation job running concurrently?

Copy link
Collaborator

Choose a reason for hiding this comment

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

The update message may be good enough for now, I hope this isn't setting up a Chesterton's Fence though!

@compnerd
Copy link
Member

The commit summary is a bit confusing - it doesn't impact MSVC builds, it impacts the VS generator.

@RKSimon RKSimon changed the title [cmake] Don't generate per-file "__SHORT_FILE__" defines on MSVC builds [cmake] Don't generate per-file "__SHORT_FILE__" defines on visual studio builds Jul 29, 2025
@RKSimon
Copy link
Collaborator Author

RKSimon commented Jul 29, 2025

Yes, it demonstrates my lack of understanding of what actually goes on in cmake vs builds - all I can see is that there is at most 2 cores being used for cl.exe and cmake.exe keeps reappearing as well.

RKSimon added 2 commits July 30, 2025 08:25
As reported on llvm#150677 - this prevents build parallelisation as cmake is repeatedly updating the cache
@RKSimon RKSimon force-pushed the cmake-msvc-no-shortfile branch from 404e6b3 to a7c24e3 Compare July 30, 2025 07:26
@RKSimon RKSimon merged commit 9a84c62 into llvm:main Jul 30, 2025
9 checks passed
@RKSimon RKSimon deleted the cmake-msvc-no-shortfile branch July 30, 2025 16:10
krishna2803 pushed a commit to krishna2803/llvm-project that referenced this pull request Aug 12, 2025
…udio builds (llvm#151167)

As reported on llvm#150677 - this is preventing msbuild parallelization as cmake is repeatedly being updated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake Build system in general and CMake in particular
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants