Building on Mac and Linux

[Grayswandir]

I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.

Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.


Anyway, as for building on linux - the only problem I had was the sound only working with oss, which I'm pretty sure I've narrowed down to how allegro was built. Since we're not interested in allegro 4.4 right now, and I won't be able to get ZC's frakenstein version of 4.2 to compile without tens of hours of work, I don't really have much more to contribute to the discussion. Take a look at my makefile if you want. It's considerably shorter, and halfway decently commented.

(The actual changes to ZC making it compatible with 4.4 amounted to around 15 lines of code. And that was all undoing the changes that somebody decided to hack into ZC's allegro because having threadsafe file loading is vitally important. )

[DarkDragon]

Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.

It's not branch 2.50.x that will be made master, it's branch cmake, and I'm not going to do this until I hear something from the other developers (and likely help them sort out how to make CMake correct configure the build on their system). What's the point in making 2.50.x the temporary master for a couple of days?

[ZoriaRPG]

Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.


Anyway, as for building on linux - the only problem I had was the sound only working with oss, which I'm pretty sure I've narrowed down to how allegro was built. Since we're not interested in allegro 4.4 right now, and I won't be able to get ZC's frakenstein version of 4.2 to compile without tens of hours of work, I don't really have much more to contribute to the discussion. Take a look at my makefile if you want. It's considerably shorter, and halfway decently commented.

(The actual changes to ZC making it compatible with 4.4 amounted to around 15 lines of code. And that was all undoing the changes that somebody decided to hack into ZC's allegro because having threadsafe file loading is vitally important. )

Oh, the threadsafe file loading was likely an attempt to prevent buggering the save file. I think that is separately resolved by preventing multiple instances as a runtime option, as that fix didn't work (?).

Mates, IDK what is happening. When Saffith said he wanted to make 2.50.x 'master', because he wanted to toss out the refactoring, and Gleeok said that'd be fine, we've all been acting under the presumption that this was finalized. That's why you can't let weeks pass when deciding these things, and then jump in and change things without public discussion and announcements of the plan.

We've all spent considerable time working on this mess, and remerging the changes is a genuine pain.

Make something main that isn't going to change. I suggest 2.50.x, stable. Make something the next dev branch. Set them in the repo, and we'll work from there, but please stop changing the plan, and doing things without discussing them in threads; so that we're all on the same page.

I'm going to again ask that the stable version slated as the next release is kept as master. That way, it's sane, and anyone who wants to build from it knows what is what. Making the development branch 'main' is just downright confusing to everyone, and it's very rarely done that way.

We can probably fix our changes in one or two days, but it's still a waste of time.

Also, is the CMake branch going to retain the MinGW/MSYS essentials? I don't particularly want to shift to CMake, especially as the way I've things configured now, it takes me all of two seconds to shift lib stuff out, and I can do simultaneous builds using the old, and the new libs without changing any paths or includes. I could use separate makefiles, I suppose, but this way I only need to decide if I use MSYS or cmd.exe to do the build. (MSYS builds on the old libs, cmd.exe with MinGW32-make does ag4.4.)

[DarkDragon]

Mates, IDK what is happening. When Saffith said he wanted to make 2.50.x 'master', because he wanted to toss out the refactoring, and Gleeok said that'd be fine, we've all been acting under the presumption that this was finalized. That's why you can't let weeks pass when deciding these things, and then jump in and change things without public discussion and announcements of the plan.

We've all spent considerable time working on this mess, and remerging the changes is a genuine pain.

Make something main that isn't going to change. I suggest 2.50.x, stable. Make something the next dev branch. Set them in the repo, and we'll work from there, but please stop changing the plan, and doing things without discussing them in threads; so that we're all on the same page.

I'm going to again ask that the stable version slated as the next release is kept as master. That way, it's sane, and anyone who wants to build from it knows what is what. Making the development branch 'main' is just downright confusing to everyone, and it's very rarely done that way.

We can probably fix our changes in one or two days, but it's still a waste of time.

Easy there. You can't complain simultaneously about 1) lack of decisive action and 2) lack of extended discussion. The discussion is happening right here and the plan is being made right here. Once Gleeok and Saffith and I are on the same page, you will have your reorganized repository. The repository has been in its current state for almost a year, another week or so won't hurt, especially (as you yourself point out) there needs to be public discussion before wildly rearranging things around. Patientez.

Also, is the CMake branch going to retain the MinGW/MSYS essentials? I don't particularly want to shift to CMake, especially as the way I've things configured now, it takes me all of two seconds to shift lib stuff out, and I can do simultaneous builds using the old, and the new libs without changing any paths or includes. I could use separate makefiles, I suppose, but this way I only need to decide if I use MSYS or cmd.exe to do the build. (MSYS builds on the old libs, cmd.exe with MinGW32-make does ag4.4.)

It will, if you help me configure it
As for switching to CMake, any alternative that is platform-specific (and a single *nix-style Makefile is exactly that) is a non-starter. I'm 95% confident that CMake can configure your Makefile to do whatever it is you want to do, i.e. support two different versions of Allegro (though I'm hoping that in short order we will all simply switch to 4.4, assuming that solves more problems than it introduces). Yes, switching to CMake is a slight pain, but in the words of Spock, "the needs of the many..."