Centralize development #14
Comments
|
You can merge my repo, but note following points.
|
|
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? |
|
When I forked from cebix/macemu, I could not build Windows version. |
|
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? |
|
Those are:
|
|
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? |
|
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. |
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:
|
I recommend individual commits. It is useful when identifying a commit where problems occurred.
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.
Here, the GUI is whether or not to use GTK. |
|
Hi, I will not work anymore on my fork, you can add the 64 Bit Slirp patch and merge it in your repo. I need a repo wich:
We need a Cocoa native GUI, and way to load Disk Images during execution, also. Is there a way ? |
Yes. The four points you presented can be realized in my repo.
It may be possible in the future. |
|
I'm lost. Wich repo should I use ? Yours /~https://github.com/kanjitalk755/macemu/ or github.com/emaculation/{BasiliskII,SheepShaver} ? |
|
@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? |
|
@jvernet
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.
Unfortunately I don't. |
|
@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? |
|
Not SDL. SDL 2. SDL 1 is EOL. But SDL 2 do not work on PowerPC. cebix/macemu is SDL1 only, so far ? |
Yes.
Yes, SDL2 only. @ianfixes
|
|
@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: Is that a file that exists locally on your machine? |
No. The link is dead. |
|
OK -- I will delete and assume that I'm not breaking anything. |
|
It involved a very scary
My next step will be to repair the builds. Those tasks are: |
|
@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. |
|
I think https://emaculation.com/forum is good. |
|
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. |
|
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 emaculation/macemu@1968051. |
|
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: |
|
Under Windows, I confirmed BII/SS can be built with MinGW/MSYS(not MSYS2). |
|
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. |
|
Refer "Build kanjitalk755's BasiliskII code in Windows". |
|
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. |
|
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: |
|
Just now I succeeded to build BasiliskII under Windows7(x86) according to the guide. |
|
Did you try pressing Alt-F4, to see if this problem still exists: |
|
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 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. |
|
@kanjitalk755 is building the linux kernel module in |
|
NetDriver is optional. |
|
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 #96 |
|
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 ( My intention was to simply shore up 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 TL;DRI'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. |
|
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
<#14 (comment)>,
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>
.
|
|
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? |
|
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
<#14 (comment)>,
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>
.
|
|
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. |
|
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
<#14 (comment)>,
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>
.
|
|
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. |
|
|
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
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? |
|
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 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 |
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?
The text was updated successfully, but these errors were encountered: