Quote Originally Posted by Gleeok View Post
We've been testing cmake on all the compilers that we could so far; MSVC 2008, 2010, 2013, 2016, and gcc 5.4. This obviously doesn't necessarily mean that it works on every other platform/toolchain, but any feedback you guys could give would be very much appreciated. Of course someone has to be the first to test it after all. wink wink.


As for multiple build/project files, DD and I seem to part ways here. He believes that there should be one system that works well that everyone can use so there's little chance of things breaking or not being up to date, which makes a lot of sense, I admit. I believe (and the way ZC was in the past was) that any developer that's willing to maintain a configuration is free to do so, as long as it doesn't break any other builds in the process (eg; cmake). Developers are really picky about their set-ups I've come to find out (myself included), and sometimes if you throw something new at them they don't like they will freak out a little bit (myself included). But the end result is that now everyone can compile the source with much less hassle so it's worth it.


PS: I'd wager dollars to donuts the 2.50.x makefile makes it's way back into master.
I'm on the other side of that fence, I feat. IMO, to ensure maximum participation--because all programmers are lazy--you need to provide a wide range of building formats. I also hesitate to change to anything new. I sort of want to try MSVC 2016, but that would likely kill my ability to run VC2008, as these probably cannot coexist; which on this system is barely able to run at all; so how would 2016 run?

At least MSYS runs, and works. Until I set u a new system, I'm stuck with that.

I would burn the old makefile in a fire. We need a new, clean makefile for this branch. One that can use the new libs, and is aware of the new objects; and had directives to do things lsuch as create ./obj/parser if it isn't there, and that uses the zcfiles/include path and zcfiles/libs paths exclusively, instead of having gcc look for libs and includes in two, or three places; which it does unless you use a command line directive to include the files.

The bottom line is that gcc runs on everything, and uses makefiles. We need a clean makefil in this build, and we absolutely need every library, and other binary file, included in the package. Don't make people compile Allegro. Don't make them compile the sound libs, and the image libs. It's a silly waste of time, and a good way to frighten off anyone who might want to do it.

I finally got @Dimentio up to speed with MSYS. I don't want to have to write a guide for building with CMAKE. Hell, even I don't know what instructions I need to issue to MSYS to do a cake on this without lookin at references. I rarely ever use CMAKE, although when I built Allegro, I had to resort to it.

One thing I'll note, is that if I had all the Allero 4.4 binary files, *.a files, and libs that @DarkDraon generated, at least I could test the drawing stuff fully, before I start shifting to this branch. It's going to take a bit of time to mere all the changes, but if I had a makefile for this, it would be much faster. You see, MSYS runs as if it was a micro-emulator, so cc is horribly slow, and CMAKE is s . l. o. w. e. r. by far.

If MSVC didn't freak out running on this system, I would in fact, just use that; but the GUI tends to freeze up, sometimes for minutes at a time, while typing.Not usable until I get newer HW. I'm pretty much stuck on the CLI + Text Editor, which to be fair, is something that I'm used to doing on Linux. I use Scintilla and MSYS on Windows; and Scintilla is extremely lightweight, so having forty source files open at one time actually works.
@Grayswandir is used to EMacs + gcc.

I'm also going to need to start doing OSX builds, so we'll see how that goes. The only system that I have running 10.6, is a netbook.

Anyhow, we need the libs in the repo, and we need a plain makefile in the repo.

I think I will try to commit some of my changes ahead of your script drawing revisions, so that if necessary, you can modify them to work with whatever you have going on with those. I know that when I tried to implement your changes, I missed somethin somewhere along the line, and while they compiled, they either didn't work, or created a flood of errors on the stack. Probably my fault, but IDK. Did you ever look at the beta that I sent to you that had them enabled? It's still on the server, if you want to see what I did, and what it was doing.

We really need to draw a line though, and stop going back to square one. This needs to be the last time that we do that for 2.54, 2.55, 2.60. We can lay that dance again for 3.0 if you wish, but no =ore for now, please.

I'm still waiting to hear if @Saffith signed off on this branch, as I don't want this to be another circular argument that ends us up at the beginning, again.

It is nice to see things moving at least, and that @DarkDragon returning seemed to light some fires.