Basilisk II / SheepShaver Code Consolidation

[webspacecreations]

Due to the large volume of code duplication between SheepShaver & Basilisk, and the likelihood it will be increasingly difficult to refactor into a single project as the two codebases pull further away from one another, what is the level of support for a merged project, e.g. "Sheepilisk?" I believe this is reflected at https://github.com/emaculation/macemu/milestone/4... is there an informal timeframe on the horizon?

Refactoring the code to reduce code duplication appears to be straightforward enough with a compile time switch (i.e. SheepShaver and Basilisk would still need to be separately compiled, but they would compile from the same codebase). Seems like a reasonable first step on the way to a single executable that would run code across the 68K/PPC spectrum. What would be needed for such a contribution to be accepted?

[ianfixes]

As far as timeline, I can't say -- the pandemic has put a lot more constraints on my time & focus.

My involvement in this codebase is first and foremost to take it into the "GitHub age" so it doesn't rot: setting up continuous integration testing (of pull requests), trimming out platforms that can't be tested in that way, and cleaning up the very artisanal system of Makefiles. As you noticed, entirely copying the codebase between Basilisk and SheepShaver is part of that... and something I would like to see less of.

As far as "what would be needed for a contribution to be accepted", I would prefer that we make steps toward CMake as a build system. Make an idiosyncratic Makefile into an idiomatic CMakeLists.txt, if you will. This is because I want to ensure that the cross-platform nature of this codebase is preserved, to the extent possible.

Is this along the lines of the answer you were looking for?

[webspacecreations]

Sums it up perfectly. Sounds like code consolidation is a low priority at the moment.

[ianfixes]

I'm not sure what you're hearing me say. Do you feel that code consolidation will be easier (with respect to existing Makefile structure) than I am making it out to be?

[webspacecreations]

I have no idea how much effort would be involved in setting up continuous integration testing. I agree that it's likely moving to CMake will be a less time consuming endeavor than code consolidation. My understanding is that CMake is really most useful when you are creating your multi-platform configuration / make build process for the first time. The artisinal work has already been done, so to speak, unless you are considering support for additional platforms or there are problems on the existing platforms. I'm not very opinionated on this matter.

More relevant (and perhaps where there's some misunderstanding) is that I'm not in a position to help with either continuous integration testing or CMake (which I'm guessing would require compilation on all the supported platforms). I feel like code consolidation, while tedious, is work that could be more easily distributable (and something I could assist with). Thorough consolidation is going to be a lengthy process, but starting with a semi-consolidated codebase that removes the exact duplicates shouldn't be too hard and would provide a foundation for further consolidation efforts even while the continuous integration and CMake build process are being completed.

My original question was related more to the logistics of how one would go about combining the two codebases in a way that meaningfully preserves the commit history for both Basilisk II and SheepShaver (versus starting clean with a new combined codebase or basing the consolidated codebase commit history on the history of SheepShaver).

[ianfixes]

One of my first attempts to bring some order to this repo involved doing what you are describing -- I wrote a script that pulled out all of the commits to both the BasiliskII and SheepShaver folders into their own standalone repos. The problem there was immediate: code is shared between the repos and some of the Makefiles were manually copying between directories. So my assessment is that any refactoring work will lean at least somewhat on refactoring the build system itself.

You're talking about doing the reverse: somehow consolidating the directories such that the code duplication goes away.

No matter how we slice that, the end result would be a codebase that avoids the copy step and uses CMake. So if consolidation happens first, the amount of CMake work is reduced anyway. TL;DR I think I've been agreeing with you the whole time -- if we can get the same compiled binaries while cleaning up the repo, that's a win. I was just curious how you were planning to approach it.

[ianfixes]

What were your thoughts on this?

[webspacecreations]

In re-reviewing the repository this was derived from, I discovered duplicate source files are aliased across the two codebases, not literally duplicated. Not exactly sure what I had envisioned, but aliasing IS one approach to centralizing the shared codebase. It might be possible to centralize a few more files with some relatively minor code changes, but not to the extent I had originally imagined. Unless you (or someone else) has closing remarks, I think it'd be safe to close this issue. Thanks for the follow-up!

[ianfixes]

Sounds like you and I arrived at the same conclusion -- the creation of aliases should probably be replaced with a build setup that's smart enough to just include files from the proper directories.