Restructuring for faster build times
I was getting increasing build times as I was adding more classes. I read the pybind11 faq about breaking up the bindings into multiple translation units. So we now still get the same result but now we can use more processors to compile and speeds up rebuilding while developing. Also we can make slightly more organized folders as the number of classes increases.
Welcome to other ideas, but I get the same results as before but build times are much faster.
Great, I've been wanting to do this as well due to build times. About the .inl filenames, it may be safe to rename these to .h now? I used .inl as they were initially just ways to split up one big .cpp file and .inl seems like the convention for that. But .h would be a more familiar convention for traditional header files, which these now look like.
Yeah that sounds good, I was debating changing it too, so I will do that next.
Looks like the mac builds have broken, and that stubs generation too. That's the problem with relying on auto-updating third party services..
We should merge this though, so that we can keep making new commits. Anything you can do about the stubs breaking? Looks like it's related to this latest commit.
- https://github.com/mottosso/cmdc/actions/runs/5269410833/jobs/9527652566?pr=33
Yeah I think I know why the stubs failed. I didn't have a binding of another class I believe. I'm fixing that now. I am also updating things to build for 2024. I'll merge on my next push.
Hmm so I have to look into why the Mac build for 2024 is failing, if the dev kit is corrupt or a change in something with the unpacking tool.
The other issue is a problem with nose and Python 3.10. see this: https://github.com/nose-devs/nose/issues/1122
I'm so close, I am still getting stuck with the mac build for some reason in 2024 and Mac OS 12. Everything is basically the same. Ideas?
Finally! It was something in cmake that xcode didn't like having a byproduct of the same file on two targets..... well we are good (for now). Merging!