Configuring overlay ports and overlay triplets through the manifest #743
Conversation
|
@microsoft-github-policy-service agree [company="microsoft"] |
|
@microsoft-github-policy-service agree company="microsoft" |
|
Currently relative paths are relative to the CWD and not to the manifest root. And I guess e2e test will come to test relative paths in manifest file and manifest root != CWD. I really like this change 👍 |
|
The only issue I have with adding this stuff into the manifest is that the manifest becomes kind of a configuration file for vcpkg instead of a clean dependency definition. Maybe vcpkg should add a new differentiation and add a |
That is, |
Wait, that's what this PR already does. @Neumann-A I think the "vcpkg.json is the durable/transitive declaration of dependencies" is unaffected here. |
Maybe the title of the PR should be changed? Or is |
|
We consider
Yes, and just like registries you could also configure overlays in |
valeriaconde
force-pushed
the
val-port-overlays
branch
from
bc6a941 to
8c674e0
Compare
Is this documented somewhere? I always thought you need to have two different files (vcpkg.json; vcpkg-configuration.json). |
That would be my fault, I don't think it is documented other than the comment I made on the PR #239. |
I added this to the docs PR I have open (currently on the description of this PR) |
valeriaconde
force-pushed
the
val-port-overlays
branch
from
a48a9e0 to
8294341
Compare
|
Thanks! |
This work is part of resolving microsoft/vcpkg#30942 / https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1979597 When overlay directories from the config were added in microsoft#743 this added a condition where VcpkgPaths took responsibility to tack on the relative path, transforming those paths that come from the config into absolute paths. I did not realize at the time that this block was repeating machinery already present in IOverlayProvider family. The difference is that, there, it always assumed the prefix would be original_cwd. As part of adding overlay-port-dirs, I needed to add the same kind of prefix handling as overlay-ports get, thus pointing this out to me. It doesn't make sense to keep two independent ways to do this, leaving two options: * Move the prefix stapling into VcpkgPaths (as done in this PR) * Move the prefix stapling related to configs down into OverlayPortProviderImpl I chose to move into VcpkgPaths for several reasons: * Plumbing the information about how to handle config paths correctly into OverlayPortProviderImpl would have added many many function parameters to large parts of the product that are only passing paths information around. * The decision to chdir in VcpkgPaths is a consideration *it* makes, and OverlayPortProviderImpl would be just as happy if the relative paths were left alone. (And in fact I think the right behavior in the future would be to remove this harmful chdir but that is not proposed right now) * Despite making VcpkgPaths do "more work" here, I actually argue that it makes the "VcpkgPaths big ball of mud" problem better, by removing parts of the code that need to consider original_cwd.
This work is part of resolving microsoft/vcpkg#30942 / https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1979597 When overlay directories from the config were added in microsoft#743 this added a condition where VcpkgPaths took responsibility to tack on the relative path, transforming those paths that come from the config into absolute paths. I did not realize at the time that this block was repeating machinery already present in IOverlayProvider family. The difference is that, there, it always assumed the prefix would be original_cwd. As part of adding overlay-port-dirs, I needed to add the same kind of prefix handling as overlay-ports get, thus pointing this out to me. It doesn't make sense to keep two independent ways to do this, leaving two options: * Move the prefix stapling into VcpkgPaths (as done in this PR) * Move the prefix stapling related to configs down into OverlayPortProviderImpl I chose to move into VcpkgPaths for several reasons: * Plumbing the information about how to handle config paths correctly into OverlayPortProviderImpl would have added many many function parameters to large parts of the product that are only passing paths information around. * The decision to chdir in VcpkgPaths is a consideration *it* makes, and OverlayPortProviderImpl would be just as happy if the relative paths were left alone. (And in fact I think the right behavior in the future would be to remove this harmful chdir but that is not proposed right now) * Despite making VcpkgPaths do "more work" here, I actually argue that it makes the "VcpkgPaths big ball of mud" problem better, by removing parts of the code that need to consider original_cwd.
This work is part of resolving microsoft/vcpkg#30942 / https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1979597 When overlay directories from the config were added in microsoft#743 this added a condition where VcpkgPaths took responsibility to tack on the relative path, transforming those paths that come from the config into absolute paths. I did not realize at the time that this block was repeating machinery already present in IOverlayProvider family. The difference is that, there, it always assumed the prefix would be original_cwd. As part of adding overlay-port-dirs, I needed to add the same kind of prefix handling as overlay-ports get, thus pointing this out to me. It doesn't make sense to keep two independent ways to do this, leaving two options: * Move the prefix stapling into VcpkgPaths (as done in this PR) * Move the prefix stapling related to configs down into OverlayPortProviderImpl I chose to move into VcpkgPaths for several reasons: * Plumbing the information about how to handle config paths correctly into OverlayPortProviderImpl would have added many many function parameters to large parts of the product that are only passing paths information around. * The decision to chdir in VcpkgPaths is a consideration *it* makes, and OverlayPortProviderImpl would be just as happy if the relative paths were left alone. (And in fact I think the right behavior in the future would be to remove this harmful chdir but that is not proposed right now) * Despite making VcpkgPaths do "more work" here, I actually argue that it makes the "VcpkgPaths big ball of mud" problem better, by removing parts of the code that need to consider original_cwd.
This work is part of resolving microsoft/vcpkg#30942 / https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1979597 When overlay directories from the config were added in microsoft#743 this added a condition where VcpkgPaths took responsibility to tack on the relative path, transforming those paths that come from the config into absolute paths. I did not realize at the time that this block was repeating machinery already present in IOverlayProvider family. The difference is that, there, it always assumed the prefix would be original_cwd. As part of adding overlay-port-dirs, I needed to add the same kind of prefix handling as overlay-ports get, thus pointing this out to me. It doesn't make sense to keep two independent ways to do this, leaving two options: * Move the prefix stapling into VcpkgPaths (as done in this PR) * Move the prefix stapling related to configs down into OverlayPortProviderImpl I chose to move into VcpkgPaths for several reasons: * Plumbing the information about how to handle config paths correctly into OverlayPortProviderImpl would have added many many function parameters to large parts of the product that are only passing paths information around. * The decision to chdir in VcpkgPaths is a consideration *it* makes, and OverlayPortProviderImpl would be just as happy if the relative paths were left alone. (And in fact I think the right behavior in the future would be to remove this harmful chdir but that is not proposed right now) * Despite making VcpkgPaths do "more work" here, I actually argue that it makes the "VcpkgPaths big ball of mud" problem better, by removing parts of the code that need to consider original_cwd.
…1522) This work is part of resolving microsoft/vcpkg#30942 / https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1979597 When overlay directories from the config were added in #743 this added a condition where VcpkgPaths took responsibility to tack on the relative path, transforming those paths that come from the config into absolute paths. I did not realize at the time that this block was repeating machinery already present in IOverlayProvider family. The difference is that, there, it always assumed the prefix would be original_cwd. As part of adding overlay-port-dirs, I needed to add the same kind of prefix handling as overlay-ports get, thus pointing this out to me. It doesn't make sense to keep two independent ways to do this, leaving two options: * Move the prefix stapling into VcpkgPaths (as done in this PR) * Move the prefix stapling related to configs down into OverlayPortProviderImpl I chose to move into VcpkgPaths for several reasons: * Plumbing the information about how to handle config paths correctly into OverlayPortProviderImpl would have added many many function parameters to large parts of the product that are only passing paths information around. * The decision to chdir in VcpkgPaths is a consideration *it* makes, and OverlayPortProviderImpl would be just as happy if the relative paths were left alone. (And in fact I think the right behavior in the future would be to remove this harmful chdir but that is not proposed right now) * Despite making VcpkgPaths do "more work" here, I actually argue that it makes the "VcpkgPaths big ball of mud" problem better, by removing parts of the code that need to consider original_cwd.
Docs PR: microsoft/vcpkg#27172