Please honour GNU Coding Standard: DESTDIR in the future.
Almost every program out there supports the DESTDIR variable, why doesn't Doomsday? 'make install' is sloppy and 'make uninstall' can be nightmarishly unreliable, but if we could 'make DESTDIR=/tmp/foo install' then we could use that directory tree as a building block for making our own safe, reliable packages for our own distributions.
Those of us on Linux need better options than 'make install' and 'use Ubuntu' for getting Doomsday running. Having DESTDIR support would give us much more control over our installation. I could make packages for Slackware that can be safely installed and uninstalled with installpkg/removepkg, for example, if this support were added.
http://www.gnu.org/prep/standards/html_ ... STDIR.html
Those of us on Linux need better options than 'make install' and 'use Ubuntu' for getting Doomsday running. Having DESTDIR support would give us much more control over our installation. I could make packages for Slackware that can be safely installed and uninstalled with installpkg/removepkg, for example, if this support were added.
http://www.gnu.org/prep/standards/html_ ... STDIR.html
Comments
EDIT: The PREFIX variable sets the built-in default locations where Doomsday searches for data files and libraries; it should be set according to the final installation location. qmake's generated Makefiles have an INSTALL_ROOT variable that controls where make installs the files. INSTALL_ROOT is currently being used by the Debian packaging scripts.
skyjake, PREFIX and DESTDIR behave differently, they're not exactly the same thing. If qmake doesn't support DESTDIR, well then it damn well should and I'm shocked that it doesn't, considering how common this standard is!
INSTALL_ROOT is Debian. DESTDIR is platform-independent Linux. Debian may be Linux, but Linux is not Debian.
Okay, I guess it's time for me to gripe a little...
I can't help but notice the Linux development seems to be rather Ubuntu-centric. I really must recommend trying your best to code for wide Linux support rather than just focusing on Ubuntu. I'm noticing a disturbing trend among more and more developers/projects that seem to ignore every other Linux in existance and it's really not good for anyone. The people who want to use your software will be limited and restricted in ways that shouldn't be necessary, and you as developers will inevitably develop bad coding ethics relying on tools and standards designed for a very particular, heavily commercialized flavour of Linux that has its own quirks, proprietary packages and unique ways of doing things.
Please don't let this project become "one of those" Ubuntu-only Linux projects. I remember using Doomsday ages ago and I was really looking forward to getting into it again. It's a shame this roadblock is in place. I try to keep a clean system with packages I can track, add and remove safely. 'make install' is old, deprecated, messy and downright invasive at worst. You may even get more people willing to volunteer with development if you opened things up to a wider userbase, rather than making it difficult for people not using your preferred distribution. If you compile software even half as often as I do, you'd know how absolutely common DESTDIR is and you'd understand how confused I am that a project that's this actively in development (and has been for so long, too) doesn't support a make variable that's common enough to take for granted in most other source.
I'm not a programmer, but I've compiled dozens of programs from source code in order to create packages for Slackware that don't exist in Slackware's repositories. And in my experience, this standard really needs to be supported. Not just for Slackware, but for every single Linux that isn't Ubuntu. It's an incredible starting point for package creation. I'll even volunteer to upload tested, completed binary packages of stable versions of deng to the site to help get a wider variety of binary packages on the download page. All I need is this variable to be supported and I'll have what I need, we can keep in touch and I'll whip up new packages whenever you need them.
The deng project began life by skyjake porting the Linux Doom source release, bringing it over to Windows (his preferred development platform at the time). Originally the project made use of various libraries such as Allegro to get it up and running as quickly as possible on the Windows platform. At this time (over a decade ago now) Windows was the sole platform that deng was actively targeting.
Jumping ahead a few years, the Doomsday Engine now exists, using an engine plus game plugin architecture yet still primarily focused on Windows. The project was now starting to receive interest from users running other platforms and crucially, skyjake began to develop an interest in the Mac OS platform in particular.
The project began to shift focus with the hope of targeting multiple platforms. skyjake began work on porting Doomsday to Mac OS and ultimately achieved that goal some time around the 1.8.6 version release (however, to date there still has not been an "official" stable release for the Mac OS platform (all releases to date have carried the "beta" moniker)).
Most of the system level components chosen in the targeting of the Mac OS platform were also available for general Linux. Consequently Doomsday soon began to actively target Linux also, with updated make scripts and support from one time Deng Team member Yagisan. At this point there was no "favoured" distribution, all were treated equally.
Fast forward a few years and the home OS landscape has started to change shape. Ubuntu had developed considerable traction where other distros had failed to do so (and largely, still are...). Like it or not, Ubuntu has distinguished itself and as such it arguably warranted greater attention.
With the history lesson out the way, I want to point out that there is little to no distro favouritism in the deng project. The engine itself has zero code which specifically targets one Linux or another. The only way in which Ubuntu gets a larger share of the spotlight is due to the fact our automated build system produces binary packages specifically geared for that platform and it's greater presence on our homepage.
I do appreciate the value of conforming to the standards of a particular platform as it makes life much easier for people.
As DaniJ elaborated, we have no political or other agenda here. However, for Doomsday to support the various Unix variants out there, the Deng Team needs more manpower: our resources are fully utilized by supporting the platforms that we presently do. In time we can enhance the build system to facilitate this; right now there are more pressing concerns.
First of all, thanks a lot for doomsday, it's really beautiful and brigs new life to these old games and lots of memories to many people. I love it. Now the problem: I create RPM files of doomsday and snowberry for RedHat Linux. Upto version 1.9.0 beta 6.9, everything worked beautifully, but with version 1.9.7 I am facing the following issue:
1. The Installation path gets embedded inside the doomsday binary file. (shouldn't it look for libraries depending on some variable within the OS itself?)
Why is this a problem? I'l try to explain it better: when an RPM is built, the system compiles the binaries from source and installs all the resulting files (usually through "make install" ) to a temporary directory. Then, these files are packaged in the RPM file and youŕe happy. However, if I use qtmake to specify the PREFIX variable for doomsday to install to this temporary directory, the binary will contain this temporary path inside and then it won't work when it is installed to the final destination (using RPM). This didn't happened before, I used to compile with no problemas and install specifying the prefix, and the binaries got built fine and installed also fine.
Any clue how can i solve this? if I wasn't clear explaining (English is not my native language) please tell me and I'll try to elaborate further.
Regards,
Germán
I posted this thread: viewtopic.php?f=9&t=985 which is related to the issue discussed in this thread. While I can work with INSTALL_ROOT, I agree with the OP that DESTDIR is more standard and it would be great if doomsday supported it. However I have two questions: Why should doomsday binary have hardcoded the libraries path? and: Can that be changed?
Regards.
Edit: I just noticed "make install" installs files in /etc/apt tree, which is exclusive to Debian and Debian-based distros (Slackware and RedHat for sure don't use it). It could be made optional or something. I understand it's useful in Debian, but it shouldn't be installed without asking in the rest of distros.
The paths are hardcoded to provide Doomsday a default location to look into if nothing else is specified. There are two hardcoded paths: the DENG_BASE_DIR and the DENG_LIBRARY_DIR. The former can be overridden at runtime with -basedir and the latter with -libdir.
How would you like to change them?
One thing we could do is to allow a Unix-only config file (e.g., /etc/doomsday/paths, or ~/.doomsday/paths) that defines the base dir and library dir. Then it's the responsibility of the package creator to define the appropriate paths and include the config file in the package.
As I explained before, qmake is responsible for generating the Makefiles and thus it is not under our control how "make install" actually behaves; so we can't just go and add a DESTDIR variable in there.
I've already fixed this for 1.9.8. The apt files will be included only if /etc/apt is found on the system.