Manifests should install dependencies earlier in build process, before the CustomBuild target
#21601
Replies: 5 comments
-
|
@vicroms, could you help double confirm? |
Beta Was this translation helpful? Give feedback.
-
|
A little bit related if you have thoughts on this as well: #20846 (It would be really nice if |
Beta Was this translation helpful? Give feedback.
-
|
I think this is the same issue as #20884. |
Beta Was this translation helpful? Give feedback.
-
|
Investigating the bug filed by @dahubley made me realize my initial proposed fix is no good. I'm updating my report above with more details. Even after the issue with my original fix is corrected, using |
Beta Was this translation helpful? Give feedback.
-
|
I've found that you can make vcpkg run before module scanning by setting the dependency via the SetModuleDependenciesDependsOn variable in your project. The SetModuleDependencies target should then respect it. However, I'm not sure if this is a public feature, as there is no mention of it anywhere. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
Manifests should install dependencies before the
CustomBuildtarget because their failure to do so means custom build tool items in a project cannot reliably usevcpkginstalled dependencies.This bug/issue is motivated by tools such as
grpcandprotobuf, which provide code generation tools to generate.h,.cpp.,.pyfiles and more. A typical way to use them is to add a.protofile to your project and provide a custom build action that invokesprotoc.exeor one of thegrpctools, generating files that are also part of the project.grpcandprotobufare both ports invcpkg, sovcpkgis a natural way to obtain them. Then the custom build action can just point to their tools in thevcpkginstalled directory, e.g.,"$(_ZVcpkgCurrentInstalledDir)tools\protobuf\protoc.exe"The problem comes when using manifest mode. The targets in
vcpkg.targetsare specified withBeforeTargets=ClCompile, which means that the manifest dependencies are installed after any files with custom build tools specified are processed. That is, in a clean setup wherevcpkghas not installed anything, a.protofile will fail to be processed by theprotobuforgrpctools that are specified, because those tools do not have a chance to be installed until after the.protofile is compiledSimply changing
VcpkgInstallManifestDependenciesandVcpkgTripletSelectioninvcpkg.targetsto haveBeforeTargets="CustomBuild"BeforeTargets="CustomBuild;ClCompile"addresses the issue. Note: I updated from the strikethrough to include bothClCompileandCustomBuild, since not specifyingClCompilebreaks the most common usage :-P . But even this isn't great, as it doesn't cover other build actions, e.g.,CudaBuildas hit by @dahubley in #20884 .Is there any reason to not make this change in
vcpkg.targets? I'm happy to submit the PR, but I'm not an expert in msbuild and the targets, so I'm not 100% sure that won't have any side effects.Environment
To Reproduce
Steps to reproduce the behavior:
vcpkgand run.\bootstrap_vcpkg.bat, and then.\vcpkg.exe integrate installvcpkg_installed\x86-windows\...hierarchy next tovcpkg.jsonor any mention in the compile output aboutvcpkginstalling dependencies. This is the bug/issue - because custom build tool items don't causevcpkgdependencies to install, they can't reliably use them.Expected behavior
Install manifest dependencies before any custom build items run
Failure logs
N/A
Additional context
N/A
Beta Was this translation helpful? Give feedback.
All reactions