Chocolate Doom

[LexiMax]

Jon said:

I have a branch (and I thought a PR but I'm not sure) where I upgraded the visual studio stuff to 2015, but I don't know if it it's still merge-worthy.

Right on time for Visual Studio 2017 to come out. See the problem here?

One thing I thought might help this would be if we got regular, automated builds via VS set up, I think this is possible at visualstudio.com. I started trying to look at this a while ago and then stopped

I have already got these set up for Odamex through AppVeyor.

https://ci.appveyor.com/project/odamex/odamex

Feel free to steal my build scripts.

Jon said:

In theory, yes. In practice, you can have a CMake thing set up that works for one platform and is broken on another, and the regular devs would still not notice.

The Chocolate Doom wiki has this to say about the existing Visual Studio projects:

You may find that these project files are sometimes slightly out of date and not up-to-date with the latest changes to the source code. You're welcome to use these alternative build systems if you're more comfortable with them, but bear in mind that they are "unofficial".

As long as CMake has the same sort of "unofficial" label that the existing project files have, I don't see this as a problem. The expectation is that if you have a pet environment you like to use and the CMake build files don't work for you, you can fix them and get your changes upstreamed.

I'm not even necessarily arguing that the existing project files vanish either. If you're a regular contributor, you have the right to a nice and cozy programming environment tailored to your needs in-tree. CMake would be for outsiders, one-time or irregular contributors who prefer an IDE.

[Graf Zahl]

Actually, CMake is really nice for command line use, too.
Once CMake has been run the generated makefiles will automatically update, so it won't need to be run more than once, unless some data gets lost.

It's not so much about replacing the makefiles but replacing autotools which is one of the most cross-platform-hostile things around.

Nobody has to go to the length ZDoom went with CMake, most of that was done to get it to the state where the CMake-generated VS project is of the same, or even better quality of the former native VS projects, which got discarded a year ago.
I have used it for other projects as well and normally made do with a relatively simple, easy to read project file that doesn't really look any worse than the makefile.am from Chocolate-Doom.

But let's not forget the main drawback of Autotools: It effectively shuts out any potential contributor on a Windows platform, having such a Unix-centric build system as the main tool, just demotivates, if the VS projects are constantly broken.

ZDoom had been suffering from the reverse for many years: The entrire focus was on VS, so the Linux makefiles were more often non-operational than not, it only got better after the CMake project worked for both platforms which I switched over to two years ago, after that point the cross-platform problems were greatly reduced.

[dpJudas]

In my opinion CMake is pretty much superior to the autohell tools in every conceivable way.

The main downside of CMake is that its documentation is extremely poor (anyone using automake should feel right at home here, though) and its custom language doesn't exactly help on it. You also have to spend quite some time to make their VS and Xcode generators output projects that suck as little as possible. And that GUI tool they have for Windows looks like a 5 year old designed it.

But once you've set up the CMakeLists.txt file it is way superior to any manually maintained project files, especially for cross platform projects.

[Graf Zahl]

dpJudas said:

In my opinion CMake is pretty much superior to the autohell tools in every conceivable way.

In my opinion, Autotools exemplifies what is wrong with Unix-style development. Some of it seems to be stuck in the 70's with little interest in modernizing tools. But when I look across the web to see what kind of people mostly use it, it's clear that those are almost exclusively 100% Unix developers with little regard of the outside world. Considering this it's a bit odd that a project like Chocolate Doom, which aims at cross-platform development does so little to encourage any development on other platforms.
Well, at least it's better than Doom Legacy which doesn't even compile on onn GNU-compilers.

dpJudas said:

You also have to spend quite some time to make their VS and Xcode generators output projects that suck as little as possible.

Correct, but once it works, that basic framework can be copied to different projects. It's not that this needs to be repeated. For anyone interested in a minimal example I'd recommend to have a look at my wadext project on Github. It's mostly a stripped down version of ZDoom's project, just enough to generate a well-working VS solution.

And just for the record: I have long abandoned the idea of actually shipping VS solutions along with a project, it's an endless hassle to get this version specific stuff working - CMake is far more flexible even when only targeting Windows, because it can be used with any MS compiler which has enough language features to compile the source.

[Siggi]

Is getting Chocolate Doom to compile with Open Watcom a thing people care about?

I've managed to get chocolate doom 2.3 to compile and run.

It did require some small changes though.
There's a compile error in doom/p_setup.c.
Also had to add a struct packing macro as Watcom C expects its _Packed keyword to appear before the struct keyword.

[fabian]

Siggi said:

It did require some small changes though.

Could you please file a pull request with these changes?

[chungy]

dpJudas said:

In my opinion CMake is pretty much superior to the autohell tools in every conceivable way.

I have to strongly disagree with this. Both the syntax of the CMakeLists.txt (did they just want to be COBOL?) and the user interface of cmake are atrocious, especially for using it to make distribution packages (yay... -DCMAKE_C_COMPILER -DCMAKE_DOC_INSTALLATION_DIRECTORY -DCMAKE_BIN_INSTALLATION_DIRECTORY ... bleh). CMake's primary benefit is making it easy to use xcode and msvc, and that's about it.

In comparison, autoconf just uses M4. It's now a somewhat obscure macro language, but it's not too bad. Automake just uses standard Make syntax, easy to understand, just a few things replaced/added in by automake itself. Plus the pretty easily-understood --prefix and DESTDIR options.

I'm still in support of having CMake as an alternative build system, especially to replace the manually-curated codeblocks/msvc ones. But I'd hope very much that autotools is not replaced by it in Chocolate Doom.

Graf Zahl said:

Well, at least it's better than Doom Legacy which doesn't even compile on onn GNU-compilers.

in fairness, it doesn't really work with current GNU compilers either.

[Graf Zahl]

chungy said:

In comparison, autoconf just uses M4. It's now a somewhat obscure macro language, but it's not too bad. Automake just uses standard Make syntax, easy to understand, just a few things replaced/added in by automake itself. Plus the pretty easily-understood --prefix and DESTDIR options.

Strange that most developers I know harbor a deep dislike for this thing and wish it could be banished from the face of the earth.

It's fine if you know that nobody outside the Unix world will use it but for everything else it should be prohibited.

And why is it necessary to ship the 200kb configure script with each project.
That alone reeks of bad design. A good tool should never make it necessary to keep an executable of it in the project, shell script or not.

Also, if it's so great, why has nobody ever tried to sanitize into a real cross-platform tool? Well, the conclusion I drew is simple: Autotools seems nice on the surface because it's too limited to do anything more than the absolutely barest minimum for building with a known compiler toolchain, so that it can hide some of the dirty stuff deep inside, which in a true cross-platform tool cannot be done.

[chungy]

Graf Zahl said:

And why is it necessary to ship the 200kb configure script with each project.
That alone reeks of bad design. A good tool should never make it necessary to keep an executable of it in the project, shell script or not.

I'm not certain of bad design, but it is legacy cruft and obsolete design. It likes to generate checks for all ranges of historical Unices that don't exist in use anymore (seriously, I think if it was limited to current versions of GNU/Linux, *BSD, Solaris, and Darwin, pretty much nobody would complain), and Chocolate Doom probably wouldn't even run on them even if you tried to do a "./configure && make" run on them.

It is a legitimate grievance, but in recent years the autoconf project has made some nice efforts at cleaning up the project (it was in "maintenance mode" for too long... heh). I don't believe it's a show stopper, honestly.

[grommile]

The fundamental original purpose of autotools was to cope with the crawling horror of getting software to build on more than one flavour of Unix in the face of the incompetence- and avarice-induced defects and inconsistencies of proprietary Unix implementations and eccentric academic Unix administrators. It was never meant to deal with anything else, and nobody who maintains it has ever cared about dealing with anything else. (Remember, it's GNU software; the convenience of developers trying to target Microsoft Windows is wrong-end-of-the-telescope territory.)

And you're far too generous to it; even most Unix people think it's well past its sell-by date. The problem is that nobody has come up with a ubiquitously acceptable-to-Unixers replacement. Some people like CMake. Some people like scons. Some people like Some Random Academic's Completely Perfect Build Language. Some people like 'write a custom Perl script to do the configuration step and mandate the use of GNU Make to process the resulting makefile'.

(Also, historically nobody in charge of autotools maintenance cared about backwards compatibility, so your project's input files for the autotools chain were only compatible with a single version.)

[printz]

I also want a CMakeLists.txt, or failing that, an Xcode project. +1. I may try making a pull request with an Xcode project, but maybe it's better to wait for CMakeLists.txt. Thing is that if it's CMake, I tend to get some resulting xcodeproj full of "target" signs and indirect build targets, which just build other targets, instead of a clean set of libraries and/or apps to produce.

[Linguica]

A while back when I was playing with Emscripten, which by default wants a project that compiles with a standard ./configure && make, and I had to go all the way back to https://doomwiki.org/wiki/LsdlDoom to find one that would compile without a huge amount of trouble.

[LexiMax]

chungy said:

I have to strongly disagree with this. Both the syntax of the CMakeLists.txt (did they just want to be COBOL?) and the user interface of cmake are atrocious, especially for using it to make distribution packages (yay... -DCMAKE_C_COMPILER -DCMAKE_DOC_INSTALLATION_DIRECTORY -DCMAKE_BIN_INSTALLATION_DIRECTORY ... bleh). CMake's primary benefit is making it easy to use xcode and msvc, and that's about it.

In comparison, autoconf just uses M4. It's now a somewhat obscure macro language, but it's not too bad. Automake just uses standard Make syntax, easy to understand, just a few things replaced/added in by automake itself. Plus the pretty easily-understood --prefix and DESTDIR options.

I'm still in support of having CMake as an alternative build system, especially to replace the manually-curated codeblocks/msvc ones. But I'd hope very much that autotools is not replaced by it in Chocolate Doom.

CMake is not great, but it doesn't matter.

By the way, you don't need to memorize the command line parameters. That's what cmake-gui (Qt) and ccmake (ncurses) are for.

printz said:

I also want a CMakeLists.txt, or failing that, an Xcode project. +1. I may try making a pull request with an Xcode project, but maybe it's better to wait for CMakeLists.txt. Thing is that if it's CMake, I tend to get some resulting xcodeproj full of "target" signs and indirect build targets, which just build other targets, instead of a clean set of libraries and/or apps to produce.

I submitted a pull request with one two years ago and it was rejected by fraggle. I'm not going to work on and submit another one unless he would be willing to accept it.

[fraggle]

Here's my stance:

• I don't want to keep adding more and more build files for every possible platform and OS imaginable. We already have three (autotools, codeblocks and MSVC). More projects means more to maintain that can get out of sync with the main ones (the autotools ones).
  
  
• Chocolate Doom should look like a standard Unix package and for me that means autotools.
  
  
• I want to be able to build things myself and I don't have a Windows system. MingW allows me to do this since there are cross-compilers for Linux. It also makes automated builds easier to maintain.
  

However, from the responses to this thread I'm seeing a lot of people who would be interested in CMake configs. What I'll emphasize is that I don't want to see more configs. If you can provide CMake configs that replace either the current Codeblocks or MSVC ones (or both) then that sounds acceptable. Indeed, it looks like CMake can also generate Codeblocks configs; if you can replace both it would be a net win.

However, I'd also like to hear from people who use the MSVC build files to understand how much more hassle it would be to force them to use CMake. If MSVC now has CMake integration then perhaps that isn't a big issue.

[Graf Zahl]

fraggle said:

Chocolate Doom should look like a standard Unix package and for me that means autotools.

I actually expect that to change. CMake will take over eventually because it's simply better.

However, I'd also like to hear from people who use the MSVC build files to understand how much more hassle it would be to force them to use CMake. If MSVC now has CMake integration then perhaps that isn't a big issue.

ZDoom has been using CMake exclusively for one year, and for one more year it was required to build with a non-ancient MSVC version, the number of complaints has been minimal. Of couse a few people in the beginning showed the same resistance as you with ditching autotools (it's hard to let go of something familiar) but things quickly went back to normal as people got used to it.

[printz]

How about getting rid of Code::Blocks and replacing it with something more useful?

[fraggle]

printz said:

How about getting rid of Code::Blocks and replacing it with something more useful?

That was one of my suggestions, I believe. I'd also like to hear from anyone who uses the Codeblocks files (if there is anyone) to see if they'd have any strong objections to this.

[Wagi]

The last time I tried to build chocolate-doom under Windows, it was impossible to do so using the "canonical" method of using Cygwin. The instructions on the wiki were mentioning packages that no longer seemed to exist in installer. Upon asking about this on the IRC channel I was told not to bother with Cygwin and modify the Codeblocks project instead.

Will switching to CMake alleviate any of this?

[grommile]

As I understand it, switching to CMake should make doing native builds on Windows using Visual Studio pretty straightforward.

[LexiMax]

fraggle said:

I don't want to keep adding more and more build files for every possible platform and OS imaginable. We already have three (autotools, codeblocks and MSVC). More projects means more to maintain that can get out of sync with the main ones (the autotools ones).

Project file proliferation is the exact reason why I'm suggesting CMake in the first place. It ought to be the last word for outside contributors with their pet environment.

However, I don't necessarily agree with it "replacing" the existing project files. I would like to reiterate that if you are a constant committer to a project, you pretty much have a license to have a "comfortable" build system in-tree as far as I'm concerned. As nice as CMake is, it's not quite turn-key, and I do not want to drag a regular committer kicking and screaming out of their comfort zone.

CMake would be for the proletariat - the one-off and occasional committers. If it doesn't work for them, then it's on them to upstream fixes to it so it does work, or simply use the known-and-guaranteed-to-work autotools if that's too much of a bother. But at least they have a choice.

So the question is - do any of the usual committers actually use these project files? If so, keep them. If not, toss them. But IMHO that should have no bearing on if CMake should be brought in or not.

fraggle said:

I want to be able to build things myself and I don't have a Windows system. MingW allows me to do this since there are cross-compilers for Linux. It also makes automated builds easier to maintain.

I have set up Odamex with AppVeyor and it works fantastically. It builds a Windows binary for every single commit using the native compiler (Visual Studio) and build tools (in our case CMake), without me having to wrangle any sort of cross-compiling nonsense.

Wagi said:

The last time I tried to build chocolate-doom under Windows, it was impossible to do so using the "canonical" method of using Cygwin. The instructions on the wiki were mentioning packages that no longer seemed to exist in installer. Upon asking about this on the IRC channel I was told not to bother with Cygwin and modify the Codeblocks project instead.

Will switching to CMake alleviate any of this?

I had a similar unsuccessful experience trying to both build and cross-build Chocolate Doom's SDL2 version. To give you an idea of how far I got, I still don't have an autotools built Chocolate Doom for Windows, and it's not for lack of trying.

From my experience doing a CMake build file for Odamex, yes, it will significantly make things easier than autotools.

[Jon]

Graf Zahl said:

I actually expect that to change. CMake will take over eventually because it's simply better.

I'm glad that CMake works for you. But, as for replacing autotools, I think if that were going to happen it would have happened already, a long time ago. Alas, it's not simply better for everyone.

Personally I support adding cmake and dropping codeblocks and possibly MSVC in the c-d sources, but leaving autotools in as the canonical system. If we dropped committed MSVC project files, I think that would kill setting up a visualstudio.com CI, though.

[Graf Zahl]

Jon said:

leaving autotools in as the canonical system.

I think that statement is the sole reason why autotools still gets used. It had been declared the standard a long time ago and because it is the standard its status as standard is not being questioned.

And the result is that there's still tons of libraries out there which are basically uncompileable on most systems because the maintainers 'only follow the standard'.

[Jon]

Graf Zahl said:

I think that statement is the sole reason why autotools still gets used. It had been declared the standard a long time ago and because it is the standard its status as standard is not being questioned.

Nope. Some people honestly prefer autotools to cmake. I'm one of them. I don't actually like either of them, but autotools is the best of a bad bunch. IMHO. (I simply hate debugging when cmake goes wrong.)

[Quasar]

Personally, if I cannot edit the Visual Studio project in Visual Studio, and have my results committed to the repository, then I just won't bother. I don't need another build tool in my life, sorry. That's always been my concern and until 2017 is the stable, de facto target, apparently this won't even be remotely possible.

Even when it is, I worry about the customized options I spent a lot of time setting up disappearing because they're not supported or because whomever ends up doing this conversion process is ignorant of them being there. This includes the optimizer settings, generation of map files which are critical for debugging release builds, etc.

This is not for lack of experience working with CMake either. I had to use it to build Strife: Veteran Edition on Linux. I did not, overall, find it a pleasant experience trying to figure out how to specify everything, to the point that I ended up buying dotfloat a copy of Doom 2016 to have him help me out with it.

[chungy]

Jon said:

Nope. Some people honestly prefer autotools to cmake. I'm one of them. I don't actually like either of them, but autotools is the best of a bad bunch. IMHO. (I simply hate debugging when cmake goes wrong.)

That reflects my feelings as well. Autotools might be bad, but it's better than much of the competition.

If it ever is supplanted as a de facto standard, it will not be by the likes of CMake. If I were to make an analogy, pretend that autotools is CVS and CMake is SVN. It might be better in some aspects, worse in others, but largely tackling the same problem with a similar solution, and plenty of projects unwilling to switch to a same-but-different system. We need the build system equivalent of Git to actually supplant autotools. (That might be in the form of something like scons or waf -- I suppose I could consider those to be "first-gen DVCS" in my analogy; where's the second-gen (ala git)? :D)

[Graf Zahl]

chungy said:

That reflects my feelings as well. Autotools might be bad, but it's better than much of the competition.

If it ever is supplanted as a de facto standard, it will not be by the likes of CMake.

We'll see. Autotools's biggest shortcoming is its platform lock-in and that's currently the most important aspect for many projects that switch.
I'd cheer myself if something with a better definition language than CMake came along, but for me the ultimate factor in decision making is not the quality of the project files but solely the extent of platforms it can target.

@Quasar: My main gripe with Microsoft is that with their project files it's virtually impossible to work on the same project with different versions of Visual Studio. On my current system VS 2005 simply doesn't work anymore which two years ago was still the target for ZDoom, but when I switched to VS 2013 I just didn't bother anymore and used CMake instead to save me from the trouble of having yet another iteration of VS solution to track. Turned out that it was the correct decision. And there's nothing worse to have 3, 4 or even 5 different projects to look out for. One will always be broken.

[fraggle]

I don't think arguing the merits over autotools vs. cmake is going to achieve anything productive. If we can focus on the main issue that would be great.

Quasar said:

Personally, if I cannot edit the Visual Studio project in Visual Studio, and have my results committed to the repository, then I just won't bother. I don't need another build tool in my life, sorry. That's always been my concern and until 2017 is the stable, de facto target, apparently this won't even be remotely possible.

Thanks - to be honest, your opinion on this was the main one I was interested in, as I consider you the main user of the MSVC project files. If you're not cool with replacing them then I'm not, either.

That leaves Codeblocks. Does anyone still use those files? As mentioned in my previous comment, CMake can apparently generate Codeblocks project files. As far as I know, none of the main committers (= the ones listed in AUTHORS) use Codeblocks. If there are no strong objections then I suggest replacing them. If there are people who do care, would it be a lot of work to update the wiki to provide some instructions on how to use Codeblocks with CMake to do a build?

[Voros]

Just came to say that I would rather keep the Codeblocks files. I plan on using them in the future, as I do have a copy of Codeblocks kept safe and ready.

[Jon]

fraggle said:

That leaves Codeblocks. Does anyone still use those files? As mentioned in my previous comment, CMake can apparently generate Codeblocks project files. As far as I know, none of the main committers (= the ones listed in AUTHORS) use Codeblocks. If there are no strong objections then I suggest replacing them. If there are people who do care, would it be a lot of work to update the wiki to provide some instructions on how to use Codeblocks with CMake to do a build?

I think JNechaevsky might be using the code blocks stuff. I'm not 100% sure, but he makes very high quality contributions (bug reports with details, videos, willing to try stuff, etc.) so I'd not want to put him off. Next time I see him on IRC I'll ask his opinion on MSVC or CMake. He will probably be happy with CMake generating code blocks files but let's get it from the horse's mouth.

[LexiMax]

Again, I do not think that the question of adding CMake should be about if it can replace a project file or not. Regular contributors have a right to a comfortable build process, whatever that happens to be.

The question should be: do you want to make it easy for irregular or one-off contributors to use their environment of choice. Being almost a meta-project file for dozens of IDE's is CMake's strength and why I recommend it specifically. There are alternatives in this category, such as premake, but the alternatives don't have the marketshare or number of generators that CMake has.