Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake support #903

Open
3 tasks done
Ozaq opened this issue Nov 17, 2018 · 7 comments
Open
3 tasks done

CMake support #903

Ozaq opened this issue Nov 17, 2018 · 7 comments
Labels
big change Likely to involve a very large and complicated change build Related to issues building dcss enhancement A request for an enhancement or feature

Comments

@Ozaq
Copy link

Ozaq commented Nov 17, 2018

I (kaisn@irc) would like to contribute to DCSS and I think this project could use an overhaul of its build system. I did ask on IRC a couple of days ago if there was any interest in moving to cmake and the response seemed be 'not against' :) As requested I am opening this issue to have a place to discuss the matter and keep it in one place.

I did spend some time to look into how much effort this might be and it seems manageable. Building just the source files on OSX was not too much work, dependencies will probably not too difficult either. Although this will take some time to get everything working.

Before continuing however I would like to know if this is something you actually would like to have and how likely you think is that i can replace the Makefile based build. I am asking explicitly about replacing the Makefile because I believe maintaining multiple build systems is a giant drain on time for everyone involved and should not be done. This does not mean however that a replacement should be done at once. A period of time where both systems are in place and can be tested is a very good thing (maybe for a whole release?).

In case you are interested in this I need to know a bit about what has to be supported in terms of build types, operating systems, distributions, packaging, architectures. Especially what is non-negotiable and what are nice to haves.

Build types:

  • Debug
  • Debug-lite (less output?)
  • Release

This is a bit more fuzzy because I don't know which of these configuration points are actually used.
Configurations (and combinations of):

  • Console (Proportional / non-Proportional fonts)
  • Webtiles
  • Tiles
  • Android
  • Android touch ui
  • No Wizard Mode

Here I have probably the most questions:
Operating System:

  • Linux (Which distributions? Should everything be build against distribution packages for distribution?)
  • OSX
  • Windows (Cross build or native?)

Edit:
###################################################################################
Progression:

  • Ubuntu 18.04 console build
  • Ubuntu 18.04 tiles build
  • Ubuntu 18.04 web-tiles build
@mossheim
Copy link

I have been lurking on this project for awhile and am a big fan. I maintain a lot of the build process at the supercollider project; just wanted to say that if yall decided to switch to CMake I would be happy to help with that/offer advice.

@rawlins
Copy link
Member

rawlins commented Nov 18, 2018

I'm sort of on a break from crawl right now but I'm probably the one who would care about this the most of anyone who is currently semi-active, so I'll weight in a bit. I think switching to cmake could be really great, and it's been on my list to investigate for a while, but it's a very non-trivial project.

Positives: It would be great because right now the build system is just straight-up Makefiles, including some custom ones from a now-retired dev written for the contribs that bypass contrib build systems and that we just try not to mess with. So there's no platform adaptability beyond what's in the makefiles, which occasionally has led to fairly messy workarounds (e.g. crawl/crawl-sdl2@5cb23d7). I think it would also improve maintainability as long as some core devs develop cmake expertise (I think right now, none of us have much experience with it). I did a relatively thorough look through possible build systems a few months ago, and cmake was definitely the one that came out ahead, for all its faults.

Negatives: basically everything in the current Makefile is used by someone, and it's a pretty non-trivial affair. I definitely agree that there would have to be a period of overlap, and I think this would potentially need to be quite long. The key thing that is missing in the summary above is that all of the public servers use the build system as well, and so part of what would have to happen for a full conversion is to make sure that this actually works on every server. These do mostly (but not entirely) share a common setup, but don't have common administrative infrastructure or personnel, and are all a bit unique in some way or the other. Some server admins are easier to contact than others. As someone who has occasionally dealt with much more trivial build changes leading to problems on specific servers, this wouldn't be much fun, and definitely isn't itself something I would recommend a first-time contributor take on because the logistics of this aspect of the problem go way beyond the code; even if I planned to do this myself I'd probably plan on a very long overlap period in order to get this working. Of course, if the resulting cmake system does converge on generating a Makefile that does everything ours does now, then that'll help, but this doesn't seem obviously like what would be best to do (and some servers apply custom patches to the Makefile in any case).

In general, one rough guide to what needs to work would be what we test on travis CI: .travis.yml, sample recent travis build. This doesn't include OS X builds and only does windows via cross-compiling.

Some specific responses:

Console (Proportional / non-Proportional fonts)

the font config is for tiles, not console (which generally runs in an terminal-like environment, so fonts are up to the terminal). Crawl ships with fonts so this isn't something people change much.

Android, Android touch ui

We don't currently support these, no one active has any expertise or even a way of compiling them. There are some third party android builds that do use these but I'm not sure of the current state of things (we occasionally get told they're broken, and they may have broken more seriously when SDL2 got upgraded last year, not sure). In the long run I imagine cmake wouldn't hurt someone who wants to get android running though.

Linux (Which distributions? Should everything be build against distribution packages for distribution?)

Mostly debian but I'm not sure of the exact way in which this works, other devs will know more; I do os x.

Windows (Cross build or native?)

Windows official packages are built via cross-compiling on linux. We support native builds via MSYS2. A contributor recently got MSVC working again (though from what I understand cmake could take this over).

@Ozaq
Copy link
Author

Ozaq commented Nov 18, 2018

Thanks @rawlins for the feedback it is very much appreciated. Indeed having server admins building from source and applying patches to the makefile makes things much more complicated. This certainly will increases the the time both systems are in place. I am however not so concerned about the logistics aspects in contacting the server admins. The goal is to have a build system in place that is more reliable, understandable and convenient and thus should be attractive to change to. Since they probably will coexist for quite some time there is no pressure for anyone to migrate their server.

Since I am under no pressure and cmake/make can coexist and be oblivious about each other there is not much that should prevent some exploration.

You can see the progress if you are interested on my fork: https://github.com/Ozaq/crawl/tree/cmake

I roughly want to progress like this:

  • 1. Ubuntu 18.04 console build
  • 2. Ubuntu 18.04 tiles build
  • 3. Ubuntu 18.04 web-tiles build
  • 4. Travis setup for cmake
  • 5. MacOS ...?
  • 6. Windows ...?

If you don't mind I would like to keep track of the progress in this issue and ask questions here that I cannot figure out from the Makefiles themselves.

After No.4 it probably makes sense to get some feedback about missing functionality, build customization.

@Ozaq
Copy link
Author

Ozaq commented Nov 18, 2018

@brianlheim Thanks for the offer I will come back to it. For now I am slogging along the issues one by one. I know cmake fairly well ad have plenty of exposure at work to it. That said I would really like a second pair of eyes for a review as soon as at least the console build is fully working.

@Ozaq
Copy link
Author

Ozaq commented Nov 29, 2018

Console can now be build, its still a bit rough and several todos are in the cmake files. I think I will postpone a first cleanup until tiles and webtiles work. Generating build files for ninja run into an endless loop regenerating cmake files indicating an issue with the dependencies. Need to investigate this at a later time.

@Ozaq
Copy link
Author

Ozaq commented Dec 23, 2018

Console & Tiles now build and can be started. Webtiles ca be started but does not yet start a game. I will have to look into how the folder layout has to be for webtiles. Maybe even create some overview doc for it.

@Ozaq
Copy link
Author

Ozaq commented May 5, 2019

Welp time flies... I had been busy with other stuff :/ But I have a version that can be used on Linux and MacOS to build.

I would like to add some documentation and then open up a PR pretty soon.
@brianlheim If you still want to look into it: https://github.com/Ozaq/crawl/tree/cmake

Feedback welcome.

@rawlins rawlins added big change Likely to involve a very large and complicated change build Related to issues building dcss enhancement A request for an enhancement or feature labels Jun 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big change Likely to involve a very large and complicated change build Related to issues building dcss enhancement A request for an enhancement or feature
Projects
None yet
Development

No branches or pull requests

3 participants