The registry allows us to overlay our own ports on top of the main vcpkg registry/repo.
Additionally, dependencies are now defined and controlled via the vcpkg.json now committed to the kicad source repo. vcpkg-configuration.json define what commit hash of both the vcpkg mainline and the kicad-vcpkg to start looking from.
If you already setup vcpkg under the old paradigm.
git clone the microsoft vcpkg mainline to anywhere on your system.
bootstrap it
Update cmakesettings.json to point to it.
Delete your existing cmake build cache, meaning the folder under <kicad_src>/build/ such as x64-Debug. (MSVC 2022 has a Delete and Reconfigure option under the Project Menu Option)
Reconfigure it in Visual Studio.
Feel free to get rid of the old vcpkg copy.
You should now see the reconfiguration step gets delayed while vcpkg install gets executed. Packages will get built and cached. The packages specific to kicad get installed to /vcpkg_installed/.
The build instructions page were updated / reduced.
Additionally a new /.vs/launch.vs.json sample is provided that is universal and should just work on any machine.
@marekr Thanks for your effort! One remark though: system Python path still takes precedence over vcpkg tools python path. You have to uninstall system Python whenever you need to update the VS cmake cache. Or not ? Does this strike only on the first vcpkg package build?
That’s a weird one, assuming vcpkg manifest was executed and the find python works now, this should not happen at all as findwxpython depends entirely on the other findpython modules.
Can you try deleting your cmake cache and letting it reconfigure from scratch?
I now remeber I did a vcpkg install python3 somewhere down the line. Sorry.
So I deleted everything vcpkg, did a fresh pull, bootstrap, new cmake cache. Now it is this:
Did you do it by switching to the microsoft vcpkg as per the updated instructions?
Does the cmake configuration log show a line that says “vcpkg install…” near the start?
A bit easier update instructions that worked for me:
In your existing kicad fork checkout of vcpkg do:
git remote rename origin kicad
git remote add origin https://github.com/microsoft/vcpkg.git
git fetch origin
git checkout -b master origin/master # or git reset --hard origin/master if you are already on master
.\bootstrap-vcpkg.bat
Then clean-reconfigure in my IDE (vscode) and that’s it.
First cmake run took a while because it still rebuilt a lot of packages and sprinkled 3gb of cache in %localappdata% and another 3gb in build dir but… cest la vie.
I think the only thing I saved in the end is a bit of bandwidth to avoid checkout full vcpkg again.
Yea it uses binary caching.
You can actually disable it if you care by setting a global env variable. VCPKG_FEATURE_FLAGS="-binarycaching"
Though do keep in mind one reason for the cache is because the vcpkg tree is now kept in the kicad cmake cache, if you delete the cmake cache, then the binary cache is the mechanism to quickly repopulate it.
I’d rather move that cache out of %localappdata% if possible because my system disk is much smaller than the one where I keep data/devtools/build trees.
Ok, works now, but only after I realized python3 is NOT in vcpkg/… any more but in Path_to_Kicad_source_dir\kicad\build\x64-Debug\vcpkg_installed\x64-windows\tools\python3.
Maybe a hint where python can be found (now) would be helpful in the MSVC build docs .
I tried updating my setup today using qu1ck’s method, but CMake is still finding the system-wide python install in C:/Program Files/Python310, calling that python.exe with -m ensurepip, which then fails when trying to build wxpython.
All paths listed in prepare-ensurepip--err.log are from vcpkg (…\kicad\build\x64-Release\vcpkg_installed\x64-windows\tools\python3\Lib\…).
Is this caused by some remnants from the old setup or an independent bug? I experienced the exact same problem when setting up the first time, which was only possible after uninstalling the system-wide python and reinstalling it afterwards.
I’ll probably try starting from scratch next, bypassing the whole old setup.
