<div dir='auto'><div>The core SCP code is built with the potentially very different set of compile time #defines that each particular simulator wants or needs.  A library oriented approach would imply N different libraries with the various different combinations of #defines that are in use and a coherent way to name and reference the resulting libraries.  Theoretically possible but a maintenance project in and of itself.<div dir="auto"><br></div><div dir="auto">The current model works for almost 50 simulators and can continue for many more.</div><div dir="auto"><br></div>Once your simulator gets to a stable state and gets merged into the github master branch, you, as the simulator author, can readily make changes to your simulator and submit pull requests that will quickly get merged. This really isn't a problem.</div><div dir="auto"><br></div><div dir="auto">- Mark<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Oct 16, 2017 3:53 PM, Seth Morabito <web@loomcom.com> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<font size="2"><div>Hello all,<br>
<br>
Has any thought ever been put into whether or not it might be a good<br>
idea to decouple the emulator implementations (VAX, PDP, CDC, SAGE, and<br>
so on) from the core SCP functionality?<br>
<br>
I ask because I've been working on my SIMH-based 3B2 emulator again<br>
after quite a few months away. Because I let it sit so long, I threw<br>
away my old SIMH working directory and built a new one from the latest<br>
SIMH source code, dropping my "3B2" directory into it and making the<br>
necessary changes to the makefile.<br>
<br>
It's always been my intention to submit the 3B2 emulator to the core<br>
SIMH package once it was in a usable state, but that means Mark is<br>
saddled with maintaining the 3B2 source code and dealing with pull<br>
requests for it. I think it would be nice if Mark could focus on the SCP<br>
functionality, and let individual emulator developers use it as a<br>
library. It could be built as libscp.a, libscp.so, libscp.dylib, or<br>
LIBSCP.DLL (depending on the platform) and just pulled in as a<br>
dependency for the individual emulators, each of which could then live<br>
in its own source code repository. (Of course, the downside to this is<br>
that the emulators wouldn't instantly get SCP bugfixes, which is very<br>
nice)<br>
<br>
I haven't given this a LOT of thought, and I'm more or less thinking out<br>
loud here, but I would love feedback. Good idea? Bad idea?<br>
<br>
-Seth<br>
-- <br>
  Seth Morabito<br>
  web@loomcom.com<br>
_______________________________________________<br>
Simh mailing list<br>
Simh@trailing-edge.com<br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></div></font>
</div>
</blockquote></div><br></div></div></div>