Adding top-level CPACK option #700
Conversation
And some sane defaults for deb/rpm packaging
| RENAME "${project_name}.png" | ||
| ) | ||
| install(FILES "${PROJECT_SOURCE_DIR}/Packaging/resources/CharisSILB.ttf" | ||
| DESTINATION "share/fonts/truetype" |
There was a problem hiding this comment.
the game doesn't look for the font here, are you sure this will work?
There was a problem hiding this comment.
On our own branch for Amiga, we have added set(TTF_FONT_PATH \"LiberationSerif-Bold.ttf\")
Shouldn't it be possible to check if target == package change font-path to /usr/share/fonts/truetype etc?
There was a problem hiding this comment.
I was emulating what the fedora rpm was doing. Where does the source look for it currently? Seems like a small-ish change for packaging to match the code, but seems like a more expected behavioral change for the code to look for it in a "standard" location.
Also, when does it get used? Because the game seems to work with or with out the font.
There was a problem hiding this comment.
ahhh, the fedora spec file has this line:
export CXXFLAGS="-DTTF_FONT_PATH=\"/usr/share/fonts/truetype/CharisSILB.ttf\""
I missed that.
There was a problem hiding this comment.
I pushed a small patch that splits TTF_FONT_PATH into TTF_FONT_NAME and TTF_FONT_DIR so I could search for TTF_FONT_NAME in 3 places:
- Current directory
TTF_FONT_DIR#ifdef __linux__"/usr/share/fonts/truetype"
It should preserve the current behavior while allowing the default build on Linux to search for theTTF_FONT_NAMEin a known good location.
There was a problem hiding this comment.
The font is used in the credits and any error message.
Your patch looks like a decent solution.
|
Nice this looks to mostly solve #212 Do you think there is any reason to keep https://github.com/diasurgical/devilutionX/tree/master/Packaging/debian and https://github.com/diasurgical/devilutionX/tree/master/Packaging/fedora around with this in place? The PPC build is failing with this change, the 7Z was just setup to replicate the generic package that i normally do manually at each release. I really like the idea of having proper distribution packages with installers and shortcuts implemented, but the downside is that it inflates the number of builds i have to do each release, and makes the list of downloads rather long when considering Linux only makes up 25% of downloads. Any suggestions for how to handle this? |
|
CPack can handle multiple targets per build, as long as it's for the same platform/arch. So it can make rpm, deb and tgz packages for x86_64 at the same time. Just add I have also looked into githubs API, and it looks like you can publish packages to a release automatically in the build process and attach the packages to the release. :) |
|
And yes, this would most likely solve #212 Amiga will have to settle for ZIP format for packaging at this point. Adding new CPack generators aren't as easy as I originally thought. Perhaps adding NSIS / WIX generator for Windows target would be a nice touch. |
Well my issue is more with crowding the download section. But I guess we could just zip all variants in one big devilutionx-linux.7z and people can pick cpu and dist from the folders once downloaded.
Yeah we where using this for MacOS but it stopped working for some reason :( It's a bit of a pain as I only have limtied access to a Mac. |
I would definitely prefer WIX over NSIS, I used to like NSIS better back in my Windows days, but the fact that it outputs .exe means that every piece of antivirus screams at it at this point :( One huge issue here though is that WIX is only available when building on Windows, and I don't. |
Not if this "works" : )
If we are OK packaging the same binary from the same build for different platforms, my Ubuntu 18.04 system is capable of producing .deb and .rpm files. I don't have a desktop fedora running around, but I am intensely familiar with building for RedHat systems, and the rpm requires and provides "look" proper. It would be a matter of building up the "list" of generators, and calling cpack.
Whoopsie, I don't include CPack or set the 7Z generator unless you specify |
|
Unfortunately, we don't know the breakdown of distros or what install method they prefer (Aur/PPA, compile from source). For Linux, I think we should go with DEB, RPM and 7Z since both Debian and Fedora users cared enough about it to contribute a setup for it, so I guess we can conclude that users of other distros are happy enough with the alternatives. So this would be the full list of potential builds I would do for a release: (Popularity will influence how many I actually prebuild) FreeBSD, OpenBSD, Haiku and Clockwork PI pretty much haver there own distribution channel. |
|
I think that's a tenable position, and it matches my experience as well. For an application with such a simple set of dependencies, the .deb and .rpm packages generated on a debian system should "just work" for most people. So how to drive this to ground? |
This initializes CMAKE_CXX_FLAGS_RELEASE during project() correctly. With out this, changes to CMakeLists.txt may result in a complete rebuild because CMAKE_BUILD_TYPE wasn't in the cache before, and wasn't respected by project(), but now it is. https://cmake.org/pipermail/cmake/2008-September/023808.html
|
Yeah I would prefer it to not be on for debug builds. For current .deb devilutionx is being build with a differne look up bath for the ttf. Not sure if that can work with out rebuilding for each package type (that's technically how it is being done now). |
And some sane defaults for deb/rpm packaging
With out trying to compete with the PPA packaging over PR #547 , this makes a sane debian package from cpack with out too much hassle. The '7Z' generator seemed .... incomplete, stuffing everything at the top level. Looks like it's only used for PPC? It shouldn't be hard to preserve the old behavior, but it seemed .... incomplete.