* improve messaging for x-script
* add newlines @ EOF
* format
* respond to Billy feedback
* test order of messaging
---------
Co-authored-by: Javier Matos <javiermatos@Javiers-Laptop.local>
Our Optional<T&> and Expected<T&> trip over the false positive described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 , where there are temporary Optional or Expecteds that return references to things outside of their own lifetime that trip the warning.
A customer wanted to run vcpkg in a place where they could not control that a `vcpkg.json` was in a directory above, and requested a way to force classic mode. One used to be able to do this with the `--no-manifest` feature flag, but that was removed some years ago.
This adds a new switch, `--classic`, which effectively skips looking for a manifest.
This work is part of resolving https://github.com/microsoft/vcpkg/issues/30942 / https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1979597
When overlay directories from the config were added in https://github.com/microsoft/vcpkg-tool/pull/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.
* Remove PrintUsage from BuildPackageOptions.
Extracted from https://github.com/microsoft/vcpkg-tool/pull/1514/
build_package never prints usage so the setting should not be there.
* Fix flipped print usage order in commands.install.cpp
The last two paths in try_load_port translated a nonexistent port directory or missing CONTROL file into errors, which is the try_load_port_required interface. No path returned the "nullptr scfl" result.
The only caller of try_load_port in registries.cpp therefore clearly wanted the "_required" behavior.
* Commonize `r`n / `n handling in test cases.
Extracted from https://github.com/microsoft/vcpkg-tool/pull/1514
Rather than each test case inventing their own way of dealing with the Windows/Linux `r`n vs `n difference, this change just always makes the output collection functions to do that transformation.
* Fix damaged -contains pointed out by @ras0219-msft
Before / after:
```console
PS D:\vcpkg\test> ..\vcpkg.exe new --application
PS D:\vcpkg\test> ..\vcpkg.exe add rapidjson
error: the command 'add' requires between 2 and 18446744073709551615 arguments, inclusive, but 1 were provided
[...]
PS D:\vcpkg\test> D:\vcpkg-tool\out\build\Win-x64-Debug-WithArtifacts\vcpkg.exe add rapidjson
error: the command 'add' requires at least 2 arguments, but 1 were provided
```
Javier Matos Denizac
Billy O'Neal
Embedded Bot
CSIGS@microsoft.com
Siyuan Ren
data-queue
autoantwort