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?
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