new versions of vcpkg don't seem to support classic mode!!
Hi,
the latest versions of vcpkg do not seem to support classic mode. I get:
What am I to do?
Regards,
JuAN
the latest versions of vcpkg do not seem to support classic mode. I get:
|
|
What am I to do?
Regards,
JuAN
Complaining about it here won't do anything, you do know that, right?
If you want a certain feature or see a bug you need to find if the issue/request has already been reported on the vcpkg github, and if not actually document it so the people who maintain the app can do the work. If they deem it worthwhile.
If you want a certain feature or see a bug you need to find if the issue/request has already been reported on the vcpkg github, and if not actually document it so the people who maintain the app can do the work. If they deem it worthwhile.
you may have to lock in an older version and stick to that one. The other options, if this is not an oversight but a going-forward-no-can-do thing, is to change your code to not need the older features.
Speaking of bugs with vcpkg....
A recent update to vcpkg apparently didn't download a specific version of powershell used by vcpkg. pwsh.exe, a PowerShell concocted to be cross platform that is entirely different than the "comes with Windows" PowerShell. So whenever a project/solution was built when vcpkg is integrated into VS the output whinged that pwsh.exe wasn't an external command, blah, blah, blah.
So, I searched the issues at the vcpkg github repo and discovered this:
https://github.com/microsoft/vcpkg/issues/35270
So, after reading the issue I downloaded the newest version of that cross-platform PowerShell, and installed it, making sure one of the install options was to add the path.
https://github.com/PowerShell/PowerShell
After some futzing around with installing this PowerShell version, making mistakes*, I finally got the "not an external command, blah, blah, blah" message to stop showing up when I compile a project/solution when vcpkg is integrated into VS.
Because I took the time to see if the issue was already reported, discovered it was, and took the necessary actions to correct the issue.
If it hadn't been reported I would have. I did that when an earlier version of vcpkg was not updating packages properly. It was deleting them and then erroring out on install.
*"making mistakes" of my own damned fault. Such as not shutting down VS, etc. Frustrating, yes, but in hindsight absolutely understandable why.
I am not a power/professional programmer, just a for-fun hobbyist. My admittedly limited expertise with vcpkg is entirely done on my own without help from others. I read the documentation the creators helpfully provide.
I have occasionally left a thread or two here at CPlusPlus, mostly to Lucy 'splain why I like using vcpkg as a package manager.
Main reasons?
1. So I can keep any 3rd party library package up--to-date as determined by the people maintaining vcpkg. There might be a bit of a time lag between a new release and when it gets put into vcpkg, but it isn't horribly extended.
2. So any 3rd party library package I download and install in vcpkg has the headers and library files treated as if they were "native" VS headers and libraries. Auto link and the IDE automatically searches for the list of headers when I start to #include the library.
Those two bullet points are well worth the price of admission. That vcpkg works with Linux/MacOS and can use CMake is an added bonus I have yet to use.
I consume libraries, I don't create one(s) that would be distributed using vcpkg.
A recent update to vcpkg apparently didn't download a specific version of powershell used by vcpkg. pwsh.exe, a PowerShell concocted to be cross platform that is entirely different than the "comes with Windows" PowerShell. So whenever a project/solution was built when vcpkg is integrated into VS the output whinged that pwsh.exe wasn't an external command, blah, blah, blah.
So, I searched the issues at the vcpkg github repo and discovered this:
https://github.com/microsoft/vcpkg/issues/35270
So, after reading the issue I downloaded the newest version of that cross-platform PowerShell, and installed it, making sure one of the install options was to add the path.
https://github.com/PowerShell/PowerShell
After some futzing around with installing this PowerShell version, making mistakes*, I finally got the "not an external command, blah, blah, blah" message to stop showing up when I compile a project/solution when vcpkg is integrated into VS.
Because I took the time to see if the issue was already reported, discovered it was, and took the necessary actions to correct the issue.
If it hadn't been reported I would have. I did that when an earlier version of vcpkg was not updating packages properly. It was deleting them and then erroring out on install.
*"making mistakes" of my own damned fault. Such as not shutting down VS, etc. Frustrating, yes, but in hindsight absolutely understandable why.
I am not a power/professional programmer, just a for-fun hobbyist. My admittedly limited expertise with vcpkg is entirely done on my own without help from others. I read the documentation the creators helpfully provide.
I have occasionally left a thread or two here at CPlusPlus, mostly to Lucy 'splain why I like using vcpkg as a package manager.
Main reasons?
1. So I can keep any 3rd party library package up--to-date as determined by the people maintaining vcpkg. There might be a bit of a time lag between a new release and when it gets put into vcpkg, but it isn't horribly extended.
2. So any 3rd party library package I download and install in vcpkg has the headers and library files treated as if they were "native" VS headers and libraries. Auto link and the IDE automatically searches for the list of headers when I start to #include the library.
Those two bullet points are well worth the price of admission. That vcpkg works with Linux/MacOS and can use CMake is an added bonus I have yet to use.
I consume libraries, I don't create one(s) that would be distributed using vcpkg.
Topic archived. No new replies allowed.