search

kanjitalk755 / macemu

Basilisk II and SheepShaver Macintosh emulators
347 stars 53 forks source link

Centralize development #14

Closed ianfixes closed 2 years ago

ianfixes commented 5 years ago

I noticed you are quite a few commits ahead of the main fork of this project, and that the main project is in a poor state of maintenance. I'm trying to set this up as a more conventional open-source project at https://github.com/emaculation/BasiliskII

Can I help integrate your work into that repo?

kanjitalk755 commented 5 years ago

You can merge my repo, but note following points.

ianfixes commented 5 years ago

Does that mean you've made edits that specifically break the windows build, or just that you haven't applied your fixes to all platforms?

kanjitalk755 commented 5 years ago

When I forked from cebix/macemu, I could not build Windows version. Then I merged rakslice/macemu and fixed, I could build it using MinGW.

ianfixes commented 5 years ago

Tomorrow I will see if I can integrate the build steps from your README.md, thank you for writing those down.

What do the 2 top sections in the README indicate?

kanjitalk755 commented 5 years ago

Those are:

ianfixes commented 5 years ago

Thanks.

It's my goal to support the build & test aspects of this project (i.e. DevOps), so that it can work as a community-driven development model instead relying on a single owner (who seems to have retired himself from the project).

As you seem to be one of the most active developers, I would prefer to make you an admin of https://github.com/emaculation, pull in all your changes, and have you continue your development there. Would you feel comfortable in that role? If not, what could I do to meet you halfway on it?

kanjitalk755 commented 5 years ago

I am whimsy and not suitable for admin.

My main work is finished.

Currently I am only making small fixes when I feel like it.

ianfixes commented 5 years ago

My main work is finished

That's good to know. My suggestion of making you admin was primarily so that you could merge your own work easily -- what I'm hearing you say is that there's not a high demand for that. Knowing that you're only making small fixes at this point also makes me more comfortable integrating your work into this fork.

That leaves 3 questions for me:

  1. Is there value in me trying to merge your work as individual commits, or would just squashing it into a single snapshot be fine?
  2. Are there other developers you've worked with as you've pushed this project forward who I should reach out to?
  3. As I set up build tests, how many different combinations should I prepare to build for? It sounds like there are the following variables:
    • platform (Linux, OSX, Windows, BSD, BeOS, AmigaOS, etc)
    • JIT / no JIT
    • GUI / no GUI
    • 32-bit/64-bit Are there any others?
kanjitalk755 commented 5 years ago

Is there value in me trying to merge your work as individual commits, or would just squashing it into a single snapshot be fine?

I recommend individual commits. It is useful when identifying a commit where problems occurred.

Are there other developers you've worked with as you've pushed this project forward who I should reach out to?

I didn't cooperate at the same time, but I merged repo/PRs of following developers.

I confirmed build and run in my repo as follows.

platform JIT / no JIT GUI / no GUI 32-bit / 64-bit
OSX no JIT no GUI 64-bit
Linux JIT no GUI 32-bit
Windows JIT no GUI 32-bit
platform JIT / no JIT GUI / no GUI 32-bit / 64-bit
OSX JIT no GUI 64-bit
Linux JIT no GUI 32-bit
Windows no JIT no GUI 32-bit

Here, the GUI is whether or not to use GTK.

jvernet commented 5 years ago

Hi,

I will not work anymore on my fork, you can add the 64 Bit Slirp patch and merge it in your repo. I will make your repo as my main branch. Can I make my repo private and closed now?

I need a repo wich:

We need a Cocoa native GUI, and way to load Disk Images during execution, also. Is there a way ?

kanjitalk755 commented 5 years ago

Can I make my repo private and closed now?

Yes. My repo is already merged your 64-bit clean slirp. My main work was to make 64-bit SheepShaver be runnable under current macOS. Thanks to you network is also usable.

The four points you presented can be realized in my repo.

We need a Cocoa native GUI, and way to load Disk Images during execution, also. Is there a way ?

It may be possible in the future. Would you like to post to github.com/emaculation/{BasiliskII,SheepShaver}/issues.

jvernet commented 5 years ago

I'm lost. Wich repo should I use ? Yours https://github.com/kanjitalk755/macemu/ or github.com/emaculation/{BasiliskII,SheepShaver} ?

ianfixes commented 5 years ago

@jvernet I'm in the process of establishing https://github.com/emaculation/ as the new home for these codebases, since the original author is apparently incommunicado. But at the moment, I'm still working out exactly how to merge all the disparate pieces of independent development. At this point, those are the folks who are most knowledgable about this project and how to build it...

@kanjitalk755 should I simply use your fork as the most up-to-date code available, and try to merge https://github.com/cebix/macemu into that?

So far I haven't been able to make contact with @asvitkine, who I think would have a lot to offer this discussion (as they seem to have merge privileges on the original repo). Do any of you know how to get in touch with them?

kanjitalk755 commented 5 years ago

@jvernet From now on github.com/emaculation is probably good.

@ianfixes

should I simply use your fork as the most up-to-date code available, and try to merge https://github.com/cebix/macemu into that?

Yes, that is the latest I think.

As a trial, I merged my repo with upstream. As a result, I could build and run without problems.

Do any of you know how to get in touch with them?

Unfortunately I don't.

ianfixes commented 5 years ago

@jvernet if I build each of the combinations listed in the table in this comment, will that demonstrate the 64-bit + SDL + OSX binary that you need?

jvernet commented 5 years ago

Not SDL. SDL 2.

SDL 1 is EOL. But SDL 2 do not work on PowerPC.

cebix/macemu is SDL1 only, so far ? kenjitalk repo is SLD 2 only ? Or you can make a choice to use either SDL1 ou SDL 2 ?

kanjitalk755 commented 5 years ago

cebix/macemu is SDL1 only, so far ?

Yes.

kenjitalk repo is SLD 2 only ? Or you can make a choice to use either SDL1 ou SDL 2 ?

Yes, SDL2 only.

@ianfixes If you would like to support as follows, it cannot be done with simple merge.

ianfixes commented 5 years ago

@kanjitalk755 there's a symbolic link here https://github.com/kanjitalk755/macemu/blob/master/BasiliskII/src/Unix/Linux/NetDriver/config.h

It refers to this nonexistent file: https://github.com/kanjitalk755/macemu/blob/master/SheepShaver/src/Unix/config.h

Is that a file that exists locally on your machine?

kanjitalk755 commented 5 years ago

Is that a file that exists locally on your machine?

No. The link is dead.

ianfixes commented 5 years ago

OK -- I will delete and assume that I'm not breaking anything.

ianfixes commented 5 years ago

It involved a very scary push -f and local merging, but this work is completed.

My next step will be to repair the builds. Those tasks are:

ianfixes commented 5 years ago

@kanjitalk755 is there a discussion medium that already includes the developers you named in this comment? I'd like to solicit their input on a few aspects of my refactor.

kanjitalk755 commented 5 years ago

I think https://emaculation.com/forum is good. It's mainly users forum, but developers also post.

ianfixes commented 5 years ago

After some consideration and experimentation, I am leaving BasiliskII and SheepShaver together for the time being. https://github.com/emaculation/macemu

When was the last time either of these built on OSX with Xcode? I'm getting linker errors.

kanjitalk755 commented 5 years ago

Because I updated yesterday (28 Mar), I confirmed that BII/SS could be built with Xcode.

The linker error is because utils_macosx.mm is reverted by https://github.com/emaculation/macemu/commit/1968051af83afe4342e0e339f8c7d7a20bbdf255.

ianfixes commented 5 years ago

Thanks! That would have taken me an embarrassingly long time to notice. OSX and Linux targets are now building properly in CI, which leaves Windows. I don't have access to a Windows machine to try the build myself, so I've been doing trial and error against Appveyor CI for most of the afternoon.

I know that I still have to sort out the library installation of SDL2 and GTK2, but if you see anything else that's amiss here I'd be grateful for your expertise: https://ci.appveyor.com/project/ianfixes/macemu/builds/23442054

kanjitalk755 commented 5 years ago

Under Windows, I confirmed BII/SS can be built with MinGW/MSYS(not MSYS2). I think some fixes needed to build with Cygwin.

ianfixes commented 5 years ago

I don't have any particular attachment to Cygwin, that was just the install script I started from. If you have a local build script that you use for windows (either CMD.exe or PowerShell) that installs the dependencies and sets up whatever paths are required, that would be a great help to me.

kanjitalk755 commented 5 years ago

Refer "Build kanjitalk755's BasiliskII code in Windows".

https://www.emaculation.com/forum/viewtopic.php?f=6&t=10019

ianfixes commented 5 years ago

Thank you... build guides have been easy to find, but so far all of them have been incomplete outdated. I'll see what I can do with this.

ianfixes commented 5 years ago

These instructions for installing SDL don't seem to work, or perhaps the build command for BasiliskII isn't sufficient to find the installed library? This is where I'm stuck: https://ci.appveyor.com/project/ianfixes/macemu/builds/23454027/job/3evq3bnfa0p3cno0

kanjitalk755 commented 5 years ago

Just now I succeeded to build BasiliskII under Windows7(x86) according to the guide. I have never used AppVeyor, so I don't know why it fails.

emendelson commented 5 years ago

Did you try pressing Alt-F4, to see if this problem still exists:

https://www.emaculation.com/forum/viewtopic.php?f=6&t=10023

ianfixes commented 5 years ago

Is that directed at me? What I'm seeing in my builds is just a failure to compile because it can't find SDL.

AppVeyor has a feature where it can spin up remote desktop at the end of the build so that you can poke around and see what might be happening. I will try a few more things... this is made slightly awkward by the fact that I can't actually run msys.bat via the AppVeyor scripting interface, as it would just open a new window in the GUI and my commands would not be redirected to that new window.

Alternatively, I could put everything into a build script and just execute the script ... but I'm unclear on how I would launch such a script in the MinGW shell you referred to in the forum post.

ianfixes commented 5 years ago

@kanjitalk755 is building the linux kernel module in BasiliskII/src/Unix/Linux/NetDriver still required to run the linux binary?

kanjitalk755 commented 5 years ago

NetDriver is optional.

gaelicWizard commented 3 years ago

What's the current news on the "central" repository? I love the idea of having an "all together" repo, but it seems like @kanjitalk755's keeping on moving forward but the @ianfixes repo is somewhat out of date (but much less out of date than some others!).

And now I see that someone has forked this repo for "flatpack" and started purging legacy code https://github.com/kanjitalk755/macemu/pull/96

ianfixes commented 3 years ago

The short answer from me is that at this point, I feel that I have failed to centralize this repository. I would still like to see centralization happen, but I'm no longer certain that I am a viable steward for it.

For context, I am a long time (20+ years) user of BasiliskII -- I first started using it before I knew how to write software (beyond Apple BASIC copied from 3-2-1 Contact magazine). When installing it on a new computer, I noticed that the homepage and github project page showed signs of abandonment -- @kanjitalk755 seemed to be providing the most support and new releases, and a few other forks had introduced some bugfixes that were not being incorporated into the main project (cebix seemed to have disappeared).

My intention was to simply shore up macemu in its entirety to what I would consider "modern" best practices for an open-source project: an organization to own it, clear contributing guidelines, issues in the issue tracker (vs a todo.txt), and continuous integration for all supported platforms. In other words, what I would consider the bare minimum for (a) giving a potential contributor the tools they need to submit improvements to the project and (b) giving the maintainer the tools needed to efficiently evaluate those contributions for correctness.

I ran into several problems:

I will take responsibility for a good chunk of the legacy code purge -- I now know that I was mistaken to assume that nobody has development environments set up on machines that haven't been manufactured in 30 years. I continue to hope that these environments can be faithfully replicated via qemu (or similar) to produce working CI builds & unit tests for these platforms... if not, I have yet to be convinced that their future is stable.

TL;DR

I'd be overjoyed to reboot my efforts to centralize this project if there is someone I can depend on to help answer questions. I have some relevant experience with GitHub, GitHub Actions, and revitalizing antique software or working around ridiculously difficult build system problems.

asvitkine commented 3 years ago

FWIW, I've been the main person "maintaining" the cebix github repo. Which has mostly been reviewing PRs and accepting them. Years ago, I had time to contribute to the project in terms of code and various contributions, but don't have the time for that these days. Though, on occasion I've made an improvement here or there.

One challenge is oftentimes contributors improve one thing, but may break support for some platform or other configuration. It is, of course, a problem with a project like this that aims to support lots of different configurations that most developers have no way of testing.

So I definitely admire the goals of having that improved - with CI testing where it's possible and any other improvements. It would be sad, however, to do those at the cost of no longer supporting older platforms (e.g. Mac OS X 10.6.8), but OTOH maybe it's a reasonable price to pay to keep SS up to date with modern ones (e.g. like M1 macs).

As such, I'm happy if the goals of one central repo/project were achieved - we could even leave the original cebix repo as the 'legacy' one that supports old Mac OS X versions if we really can't support them in the new repo.

OTOH, there's not too much I can personally contribute here - since most recent development has happened in other people's forks. So really, you need to get kanjitalk755 on board since his fork is the most up to date (and whose builds are used by the emaculation forums). If you can get him on board with your plan, then I think it would be a success - since the main challenge is having the new repo have all the latest developments, which are basically in his fork. If you can then help run the project side of things, setting up GitHub stuff like CIs, releases - that could be a great team.

I'm not sure where I'd fit in this picture - I'm happy to review code from contributors, on the other hand this could slow things down and maybe that's undesirable if it would impede contributions... (But anyway, since my time is scarce, I'm not sure my involvement is even necessary - but I'm happy to bless the new repo as official and do whatever may be helpful with my limited time.)

As for the three different projects in one, my personal thought is someone should aim to merge B2 and SS into a single binary. It should definitely be possible. Roughly:

  1. For all non-identical functions/globals that appear in both code bases with different implementations, prefix with ss or b2 and update call sites.
  2. Rename files similarly, for files that appear in both codebases but are distinct. Update includes.
  3. Handle any ifdefs conflicts (e.g. from config.h or otherwise).
  4. Have a command line switch that runs either ss_main() or b2_main().
  5. Link everything together. Have command line switch control which mode of operation is used.
  6. Long-term, slowly refactor the code to eliminate duplicate logic where it could be shared (e.g. no need for multiple slightly different implementations of something if one could handle all the cases).

But it's not a trivial project - it would require quite a bit of work. But I think it would be much better than the current hacky setup with symlinks/copied files...

On Mon, Aug 2, 2021 at 9:38 PM Ian @.***> wrote:

The short answer from me is that at this point, I feel that I have failed to centralize this repository. I would still like to see centralization happen, but I'm no longer certain that I am a viable steward for it.

For context, I am a long time (20+ years) user of BasiliskII -- I first started using it before I knew how to write software. When installing it on a new computer, I noticed that the homepage and github project page showed signs of abandonment -- @kanjitalk755 https://github.com/kanjitalk755 seemed to be providing the most support and new releases, and a few other forks had introduced some bugfixes that were not being incorporated into the main project (cebix seemed to have disappeared).

My intention was to simply shore up macemu in its entirety to what I would consider "modern" best practices for an open-source project: an organization to own it, clear contributing guidelines, issues in the issue tracker (vs a todo.txt), and continuous integration for all supported platforms. In other words, what I would consider the bare minimum for (a) giving someone the tools they need to submit improvements to the project and (b) having the tools needed to evaluate those contributions for correctness.

I ran into several problems:

  • There is scant documentation on setting up one's development environment (dependencies, etc) for any of the platforms.
  • The project is a monorepo containing 3 sub-projects that would ordinarily be thought of as 3 separate GitHub repos (more on this in a sec)
  • The style of the Makefile configuration is a bit dated -- hand-configured instead of using something like autotools or cmake to handle cross-platform stuff.
  • Basilisk and SheepShaver share code. Literally -- the Makefile copies code from one tree to the other during build 😨
  • At some point, development resumed on the main fork of the project -- some developers were given admin access, it looks like
  • It's unclear which developers are best placed to answer questions to newcomers, and incidents involving some nasty communication (like the one resulting in the fork for flatpack) left me uncertain about the level of cohesion among the developers here

I will take responsibility for a good chunk of the legacy code purge -- I now know that I was mistaken to assume that nobody has development environments set up on machines that haven't been manufactured in 30 years. I continue to hope that these environments can be faithfully replicated via qemu (or similar) to produce working builds & unit tests for these platforms... if not, I have yet to be convinced that their future is stable. TL;DR

I'd be overjoyed to reboot my efforts to centralize this project if there is someone I can depend on to help answer questions. I have some relevant experience with GitHub, GitHub Actions, and revitalizing antique software or working around ridiculously difficult build system problems.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanjitalk755/macemu/issues/14#issuecomment-891443277, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEJ4CWBVZVXGYBQXXZJMLT25CCLANCNFSM4G3EOAKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

ianfixes commented 3 years ago

There is one excellent contribution that can be made by a maintainer: make the decision on whether platforms that can't be built on GitHub should continue to be supported. I'm happy to help establish a functioning compilation environment for as many platforms as possible, by any means that are necessary (emulation, etc). But someone with authority on the future of the project needs to make that call one way or the other.

In my opinion, any & all refactoring work being discussed here would be guided by compilation tests succeeding or failing; I don't see how it would be practical to accomplish that [to any degree of confidence] without a cross-platform build farm ready to vet the proposed changes.

Windows, Linux, and MacOS are readily available in GitHub Actions. What other platforms should we make an effort to emulate?

asvitkine commented 3 years ago

Apologies for the late reply.

I still think it's up to the people who will be maintaining the new project and if the above makes things easier than I can't fault anyone for that. We can still keep the old cebix repo around for those other platforms.

In terms of my preference? It would be to keep support for the other platforms - at least at a best effort basis. (e.g. they may break from time to time, but to still accept patches to fix them). But it's up to the people doing the work on the project to ultimately decide if that's what they want - or whether simplifying and not supporting at all is what they'd like.

On Wed., Aug. 4, 2021, 10:55 a.m. Ian, @.***> wrote:

There is one excellent contribution that can be made by a maintainer: make the decision on whether platforms that can't be built on GitHub should continue to be supported. I'm happy to help establish a functioning compilation environment for as many platforms as possible, by any means that are necessary (emulation, etc). But someone with authority on the future of the project needs to make that call one way or the other.

In my opinion, any & all refactoring work being discussed here would be guided by compilation tests succeeding or failing; I don't see how it would be practical to accomplish that [to any degree of confidence] without a cross-platform build farm ready to vet the proposed changes.

Windows, Linux, and MacOS are readily available in GitHub Actions. What other platforms should we make an effort to emulate?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanjitalk755/macemu/issues/14#issuecomment-892727935, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEJ4EN2SANTN4BMKERKJTT3FIH5ANCNFSM4G3EOAKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

ianfixes commented 3 years ago

It occurred to me that there is a better first step than "set up CI and dump the platforms that it can't support"... I'd like to find out where the users are for these more obscure platforms, so I can work with them directly to help get a working environment up and running via Qbox / Qemu or similar.

I put out some feelers locally (there is a computer museum in my state), to find out if there are folks who can advise on any of this. Are you in touch with such a community? I'd like to start there.

asvitkine commented 3 years ago

I would suggest asking on the emaculation forums and also seeing if there were contributions on GitHub fixing support for any of these platforms.

On Mon., Aug. 9, 2021, 5:51 p.m. Ian, @.***> wrote:

It occurred to me that there is a better first step than "set up CI and dump the platforms that it can't support"... I'd like to find out where the users are for these more obscure platforms, so I can work with them directly to help get a working environment up and running via Qbox / Qemu or similar.

I put out some feelers locally (there is a computer museum in my state), to find out if there are folks who can advise on any of this. Are you in touch with such a community? I'd like to start there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanjitalk755/macemu/issues/14#issuecomment-895574714, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEJ4GL42ELDGDULO2LZLTT4BEU5ANCNFSM4G3EOAKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

ianfixes commented 3 years ago

Would you be willing to kick off / moderate that discussion thread? I would be a relatively new & unknown user on that forum, so (1) wouldn't know where best to raise the question and (2) wouldn't be familiar with the normal pace of discussions on that board.

RonaldPR commented 3 years ago
  1. BasiliskII and SheepShaver have separate forums on Emaculation forum. You could start a topic in the "General Macintosh Emulation" forum and ask forum members for their opinion.
  2. Do you already have an Emaculation forum account? If so, by which name?
  3. Why did you use "emaculation" in the name/address for your repo while the repo is not related in any way to Emaculation.com?
ianfixes commented 3 years ago

I will start a topic there. I had been getting by with simply reading the forums and reaching out to members via GitHub usernames, but now I've created the user ianfixes on there and will take your advice about starting that discussion.

Why did you use "emaculation" in the name/address for your repo while the repo is not related in any way to Emaculation.com?

The short answer is "so that I could hand it off to a member of that community".

The long answer is that ~3 years ago I was trying to find out where the codebase and developers for BasiliskII had ended up. What I found was:

So all signs pointed to emaculation.com being the de facto owners and maintainers of the code. I can't find any sign of a more relevant community that both uses and furthers the development of projects like BasiliskII, SheepShaver, etc.

It was and is my intention to add any & all interested parties from the emaculation.com community as administrators and remove myself from that role. I believe that to be far more sensible than attempting to do development out of a repo that is tied to a mostly-dormant github account. This is based on my own personal opinion that in 2021, a healthy-looking GitHub organization is a more sustainable place to host, collaborate on, and release software than in a forum. But I didn't get very rapid responses from the people I tried to contact, and then later the pandemic hit.

Can I add you as an admin on the emaculation github org?

RonaldPR commented 3 years ago

Emaculation.com is not the owner of te code. It is a community of users of various Mac emulators, some of which also contribute to the source. New builds of BasiliskII and SheepShaver from source are posted in the forum by more experienced users, like myself.

The last regular BII/SS developer, Gwenole Beauchesne, stopped working on the source around 2006. Many different developers have contributed since. The original source code was moved from sourceforge to GitHub cebix/macemu in 2012. The owner is Alexei Svitkine (asvitkine).

Various forks have been split off, each with its own advantages. A couple of years ago kanjitalk755 merged some of the more interesting forks together in his fork on kanjitalk755/macemu As that fork was then more advanced than the original source, we switched around 2018 from cebix to kanjitalk755 source for the builds posted on emaculation forum. Improvements are made by kanjitalk755 himself, but also others contribute.

Both kanjitalk755 and asvitkine have emaculation forum accounts, asvitkine under a different name.

No, I am not interested in being added as an admin on emaculation/macemu