KiCad testing and debugging in VMs

If you can recommend a particular distro I’d be interested in giving it a go with VMWare 15.5. Were the issues with running / debugging or compiling in a VM?

Why? I have kicad 4, 5 and nightly installed on my windows pc and they work fine.

reductio ad absurdum: might as well give up on it entirely.

that was not explained to me on the bug tracker, my guess is that configurations might interfere, and the uninstall may not be clean.

Probably because it’s a pro user topic or maybe your discussion took place before nightly had it’s config directory separated. Currently it’s very easy to have both nightly and latest stable installed, they don’t interfere. Kicad 4 and 5 together is a bit tricky but reasons to have kicad 4 are few and usually because of specific needs.

1 Like

It’s probably more fair to look at the feature freeze milestone, at least the slope is the correct direction :slight_smile:

At this point in time the 6.0.0-rc1 milestone is mostly the place we put stuff that we think can be done after feature freeze, so it will not go down very quickly.

1 Like

All good efforts are given in Elon time :slight_smile: some delays may be expected.
I think one of the key factors of KiCad’s success is its diverse user base. I mean, wxWidgets has taken quite a toll on the KiCad progress, but ultimately progress is being made, despite the neysayers who’d prefer to exclude as many users as possible, ideally only supporting Linux and distributing the source. I guess there the concept of “users” got lost along the way. I’m just tired of the cynicism.

Please note that our official policy on supporting distribution versions is that the distribution needs to be supported by its developer. It is not reasonable to ask a small team of volunteers to support operating systems that have been abandoned by their own companies.

We do offer professional support (paid) for users who want/need to use older or esoteric operating systems.

1 Like

Not to mention holds back progress by supporting a decade old OS and not being able to support newer OS features. There’s quite some shiny Windows 8+ APIs I really want to implement. I already snuck in a Windows 7+ (no XP) feature awhile back :wink:

KiCad definitely doesn’t work on XP due to not even our fault. MSYS2 and cygwin broke the compatibility for us (they were being held back without the newer APIs) :smiley:

And developers running Windows 7 at this point in time is a massive security risk and vulnerability to the project. It’s an unpatched insecure OS.


OSS has always been about the user and their freedom to build their own sand castle from source. It’s never been about having the developer beholden to demands of users. Developers certainly do care about issues and fixing them, but there’s a line in the sand in regard to what and how much can be supported on a volunteer basis and their own personal interests.

This is where the market for commerical support comes for OSS like Seth offers :wink: You now pay someone to make helping you their personal interest.

I’m tempted to go KiCad Pro, if only to create an incentive to read past the first paragraph :slight_smile:
I’ve now restructured the initial post because this thread is about helping identify bugs with the platforms that are explicitly supported irrespective of the host system, and doing so in a manner that does not invalidate the findings and the user efforts.

I still stand by statement that the initial observation under Win7 SP1 64bit is valid and can only hope that you appreciate the extra effort I put into confirming this observation setting up a Win10 VM - and making sure it runs without causing additional question marks (like OpenGL bugs).

Perhaps you could now comment on what does constitute a usable test environment. I’ve tried to outline criteria above, but I’m looking for baseline requirements and some consensus on the method of testing in VMs itself (obviously including OS-X and selected Linux distros, so not limited to Windows versions).

1 Like

I guess we shall note that “We” as in “KiPro / KiCad Services Corporation” which is not a super set of all contributors using their spare time :slight_smile:

I think this was fixed upstream for MSYS2 again a bit later. Or we are not talking about the same thing.

1 Like

It seems the test builds and nightlies still overlap. Currently having 5.99.0-2286-g30eef410a installed, so more uninstalling and re-installing, I guess :slight_smile:

image

It overwrites only the previous installation in the selected location. Just take care that you select different directories for 5.1 and 5.99.

The installer is responsible for the Windows start menu shortcuts, too, but unfortunately they don’t work well with two installations. Details can be found in Running several KiCad versions on the same Windows machine.

KiCad itself takes care of the configuration location.

1 Like

Thanks for the hint. What’s more, I’ve noticed that Windows does not handle file associations properly, as it takes the application filename only. So having multiple kicad.exe variants is bad mojo.

That’s very annoying indeed, I can’t open a file with file explorer / Open With… But we have to live with that or report it to MS. I have decided to open KiCad application first and use its Open Project etc. even though it feels stupid.

I think it would be possible to build KiCad with different executable names, but would it be worth it?

don’t think it would be worth the fallout when updating and what it would mean for end users. At this point I might as well clone the VM and never look back :slight_smile:

I’ve added a solution to this in the initial post - the trick is to register context menu entries for each of the file extensions, and a context menu item for each KiCad version installed. Works a treat under Win7 and Win10.

2 Likes

I think this is a good effort and personally am always happy when we can have more testing of KiCad.

From a developer’s point of view, I wanted to clarify a few things:

  1. If someone files a bug that they reproduced on a VM or unsupported operating system, I will not personally rush to say “won’t fix”, I will generally try to reproduce it on my own system. It is only when we have trouble reproducing the bug on a system we currently support that we run into problems, and some bugs are reproducible anywhere you run KiCad.

  2. Most of the bugs that are system-dependent or might be affected by running in a VM have to do with graphics and window management. So, when we see bugs in these areas, we are automatically a bit more suspicious if the bug is reported from a VM or unsupported OS. Historically these types of bugs have been some of the most time-consuming to fix, so that is why sometimes it seems like the developers are sensitive about not wanting to fix issues that happen on unsupported systems.

This doesn’t mean that testing on VMs is not useful! In fact it can be very useful and I do it myself sometimes. I just hope this gives some better perspective on why sometimes people on the bug tracker rush to warn people about the fact that the system they are testing on is unsupported.

4 Likes

most free software is easier to use/build/debug in a unix envrionment. I think kicad should drop windows entirely

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.