Setting up Windows (VS) build environment Oct '24

Software
1

This is a list of problems experienced when setting up a Windows build environment, and how they were resolved. Perhaps people can chime in on whether I made any mistakes along the way and should be doing things differently. Otherwise, this could be useful for the googlers!

Note that the errors I faced are largely down to external software versions throwing a spanner in the works, and will likely be resolved in time as KiCad catches up with Python versions and Visual Studio implements compiler fixes. However for end of October '24, these are issues that a new developer can expect to run into.

A number of the steps are direct from the Windows (Visual Studio) build guide, others are my best guesses.

The steps I followed:

  1. Installed latest Visual Studio with the C++ toolset and CMake tools for Windows.
  2. Created a fork of the repo ā€œ/kicad/code/kicadā€ into my own gitlab account
  3. Cloned the forked repo onto my computer
  4. Cloned vcpkg onto my computer
  5. Copied the KiCad CMakeSettings.json.sample to CMakeSettings.json
  6. Edited the KiCad CMakeSettings.json to update the following to point to my vcpkg { ā€œVcPkgDirā€: ā€œD:/vcpkg/ā€ }
  7. Opened the KiCad folder in Visual Studio - CMake started downloading / compiling dependencies. This takes some time.

This led to the first error:

error: building wxpython:x64-windows failed with: BUILD_FAILED

A little higher up in the build log are instructions to investigate get-pip-x64-windows-err.log for more information. This logfile contains the error ModuleNotFoundError: No module named ā€˜distutilsā€™.

NOTE that the following fix will go out of date when KiCad catches up to the Python version in vcpkg

Marekr helped me sort this out. It seems vcpkg updated the default Python version sometime in October, and the new version removes the depreciated distutils. The solution was to checkout an earlier version of vcpkg. I chose to go with the last commit in September.

I use TortoiseGit for these things, and Iā€™m not in any way an expert (but Iā€™m learning!) so for reference, the way to downgrade to an earlier version of the repo in TortoiseGit was to right-click in the vcpkg folder to get to TortoiseGit context menu and select ā€œShow Logā€. Then right-click on one of the log entries (in my case, last one for September '24) and select ā€œReset Master to Thisā€. Finally - and the bit that tripped me up - select the checkbox for a Hard: Reset working tree and index.

To verify that this worked, check the contents of vcpkg/scripts/cmake/vcpkg_find_acquire_program(PYTHON3).cmake doesnā€™t reference Python 3.12.x.

At this point, I deleted my KiCad clone and cloned it again to make sure it was fresh. Probably didnā€™t need to, but seemed a good ideaā€¦
Then back to Step 7:

  1. Opened the KiCad folder in Visual Studio - CMake started downloading / compiling dependencies. This takes some time.
  2. Downloaded swig (got version 4.1.1 to avoid any other version issues)
  3. Updated the CMakeSettings in VS to point to SWIG
  4. Optimistically hit the Build All

And another error! This time, it was when compiling pcbnew_wrap.cxx (generated by SWIG). Something about ā€œexpected an expression instead of a typeā€ (I neglected to get this error verbatim, sorry).

This error turned out to be the MS compiler having bugs. I was using the release version, 17.11.5. Finding an open issue on GitLab led me to change my VS version (in VS, Help->Check for Updates, and in that window, ā€œChange update settingsā€, then shift the update channel to preview which as of writing was 17.12.0 preview 5). Obviously this is a very time-specific fix and will be out of date when VS pushes the fixes to the release - but hopefully at this point, the error will no longer happen anyway!

So, following this fix, back to step 7:
7) Opened the KiCad folder in Visual Studio - CMake started downloading / compiling dependencies. This takes some time - even more so because new VS recompiles all dependencies again.
8) Already have SWIG
9) Already set SWIG up in CMakeSettings
10) A little less optimistically hit the Build All

And eventually, after everything seemed to be going so well, I got ā€œBuild All Failedā€. Scrolling all the way to the top of the output, I discovered fatal: No names found, cannot describe anything.

So - final fix. I tracked this error down to there being no tags in my fork of KiCad. To get the tags cloned across, I found the following instructions (command line Git usage here). MyKicadCloneDir is the directory in which I cloned KiCad:

> cd MyKicadCloneDir
> git remote add upstream https://gitlab.com/kicad/code/kicad.git
> git fetch upstream
> git rebase upstream/master
> git push
> git push --tags

The final command hung on me first time I used it - so after 10 minutes of no activity, I hit Ctrl+C to cancel it and ran it again.

Following all this, I can see in the web browser that my fork of KiCad now has tags, and the command git describe --tags works now.

Finally, step 10)
10) Slightly more optimistically hit the Build All

And horray! Build succeeded.

I hope this huge post is more useful than annoying, even though much of it will go out of date as software versions progress. But in the meantime, I know if Iā€™d found this post while googling, Iā€™d have been very happy!

4 Likes
2

This was of great help. Thank you so much! I would like to add a few things:

  • I cloned the latest version of vcpkg and then did git checkout 2024.09.30. This appears to be the latest vcpck release with python 3.11. I donā€™t use TortoiseGit, but I assume this should be possible with TortoiseGit also.
  • Instead of forking the kicad repo, it is easier to just clone it directly from the kicad gitlab repo. This will also preserve all the tags and you wonā€™t run into build errors later on.
  • I did use the latest swig version (4.3.0). Which seemed to work fine. At least I havenā€™t run into any problems yet.
  • Visual Studio is now at release 17.12.0, so no more need to install any preview releases. Just update Visual Studio to the latest version if it isnā€™t yet.
2 Likes
3

I forked as I thought this was the best way of keeping my own version to experiment with (if I ever find the time) without polluting the main repo with a new user. I wasnā€™t sure if I should be forking or cloning from the main repo to be honest!

So far, all Iā€™ve done is set my cloned version to 8.0.6 and figured out how to build on Windows and Linux! Iā€™m in the middle of a project where Iā€™m actually using KiCad right now, but after thatā€™s in a good place, Iā€™ll get my hands dirty I think.

On Linux, I wound up compiling from source and installing, as the version I was finding with apt-get was out of date and the snap store version had other issues (I donā€™t recall exactly what). But as Iā€™m designing a PCB between Windows and Linux computers, I needed enough version parity for file format compatibility.

1 Like
4

If you want to keep up with the changes in the official repository, cloning directly from the official repository is better. If you want to develop KiCad and hope to get your work merged to the official code, you should fork.

2 Likes
5

eelik and PolyVinalDistillate, Thank you for clarifying. What would have to be done to replace distutils with setuptools? Is this a kicad issue or rather a problem with wxpython?

6

Neither. Itā€™s a cascaded issue because vcpkg does not officially support python plugins, I ducktaped the shit out of it to make it build wxpython. Vcpkg recently updated to 3.12 but we donā€™t do that because that can break plugins, until the next kicad major release. And vcpkg pinning isnā€™t working for the vcpkg module creating the wxpython build issue for some reason. The pinning would otherwise fix the build issue.

Tl;Dr Iā€™m on vacation in Japan for 5 more days and will eventually fix it when I get back

2 Likes