Also, do you have any recommendation on how to determine if the plugin is loaded in V6 or V6.99/V7? I guess I can do a “try - except” on some random api call that have been changed, but maybe there’s a smarter way?
Thank you! If @marekr would find the time to generate the docs, that would help a lot. Since V7 isn’t far away, it would be nice if as many plugins as possible were working at the time of the release.
Sorry, bad choice of words from my side. What I was trying to ask for is a way for the plugin to detect which KiCad version that’s currently being used.
I can do this by simply trying an api call that’s not available in V6.99.
try:
# This call is only available on V6, not V6.99/V7
plot_options.SetExcludeEdgeLayer(True);
except:
# Seems like V6.99/V7 is being used.
pass
But maybe there’s a more elegant way? Something like:
I chose to use copious amounts of hasattr calls to detect what API is available.
Easy way to tell v6 from v5 is FOOTPRINT vs MODULE classes. I don’t know an easy way to tell v6 from v6.99 but it’s not that different overall. A lot less changes compared to the jump that was v6.
If you are releasing your plugin to work on 6.99 I’ve found the pcbnew.GetBuildDate() also useful. You can catch users with old nightly versions trying to run a plugin which depend on a recently added feature.
What about with full compilation? I’ve compiled KiCad before, but it’s been about a year since the last time. I checked the documentation (Build | Developer Documentation | KiCad), but it doesn’t say much about how to generate the documentation. From what I can see, all it says is that Doxygen is only needed if the documentation shall be generated. How do I generate it?
You actually don’t. swig generates its nonsense based on headers, it doesn’t need compilation.
Unforunately, the current problem is the cmake target for python doxygen is broken currently (I tried to get nightly python doxygen going). It never should have worked and has some really oddball behavior.
custom target A depends on custom command output
custom target B also depends on the same custom command output
custom target A deletes said output but comments “force removal so its regenerated”.
I have yet to find any documentation that cmake was ever supposed to do just magically rerun the custom command for target B after already doing so for A. The only change recently was switching to DEPFILE instead of DEPENDS for the custom command so maybe there’s some undocumented cmake behavior that changed