Fed up with Make. Is there a better way?

Started by
22 comments, last by Jan Wassenberg 14 years, 1 month ago
Quote:Original post by implicit

I'll check it out. I don't have a problem with Java as long as it works out-of-the-box on whatever run-time comes bundled with Windows.


You don't install it, you put in on a server, then it monitors whatever data stores you have, and acts upon them.

If you're dealing with non-technical people, teach them either how to use versioning software, or better yet, dropbox. Do the heavy lifting yourself.

In practice, deploying build systems to Joe User isn't viable, since there are too many variables to account for, just Windows is a nightmare, *nux even moreso.
Advertisement
Quote:Original post by Antheus
You don't install it, you put in on a server, then it monitors whatever data stores you have, and acts upon them.

If you're dealing with non-technical people, teach them either how to use versioning software, or better yet, dropbox. Do the heavy lifting yourself.

In practice, deploying build systems to Joe User isn't viable, since there are too many variables to account for, just Windows is a nightmare, *nux even moreso.
Oh... Then I'm afraid that's not going to work. My first priority is to get artists to actually *work* on my game projects, and I'm having enough trouble as it is getting people to run simple command-line tools.

On a related subject, I see that Waf and SCons are Python-based. Can I extract the interpreter and whatever libraries are necessary from the Python distribution, such that they can be packaged up with everything else needed to compile the project in a tidy little archive? Bouncing ZIP-files around by email is about the highest level of complexity I'm willing to risk here.
Quote:Original post by implicit

Can I extract the interpreter and whatever libraries are necessary from the Python distribution, such that they can be packaged up with everything else needed to compile the project in a tidy little archive?


Think about this for a second. Build system is just a script of sorts. It relies on everything else, obscure things you consider, um, ... implicit. Such as configuration for ld so it works with that distribution's elf. GNU make does this first time it runs, and this is what those hundreds of "checking for..., has a ...., ...." messages are. They are combined 30 years of hard work and real world experience on what all goes on just on common distributions.

The reason makefile is such a mess is because it needs to install and configure actual tools. You cannot package everything unless you make a bootable Linux distro on a CD or USB. Then there's licensing restrictions, you cannot distribute MVS and DX or even debug runtimes.

It's not the make tool, it's the execution environment which includes the OS itself.

On Linux, things are fairly easy, use apt. On Windows, you'll need to write a list on how to download, install and patch all the actual tools you use (you cannot distribute most of them, nor automate them) + a zip file that does your own stuff.
Quote:Original post by Antheus
Quote:Original post by implicit

Can I extract the interpreter and whatever libraries are necessary from the Python distribution, such that they can be packaged up with everything else needed to compile the project in a tidy little archive?


Think about this for a second. Build system is just a script of sorts. It relies on everything else, obscure things you consider, um, ... implicit. Such as configuration for ld so it works with that distribution's elf. GNU make does this first time it runs, and this is what those hundreds of "checking for..., has a ...., ...." messages are. They are combined 30 years of hard work and real world experience on what all goes on just on common distributions.

The reason makefile is such a mess is because it needs to install and configure actual tools. You cannot package everything unless you make a bootable Linux distro on a CD or USB. Then there's licensing restrictions, you cannot distribute MVS and DX or even debug runtimes.

It's not the make tool, it's the execution environment which includes the OS itself.

On Linux, things are fairly easy, use apt. On Windows, you'll need to write a list on how to download, install and patch all the actual tools you use (you cannot distribute most of them, nor automate them) + a zip file that does your own stuff.
All of that is certainly true for regular C development but this is where the beauty of hacking on small C64 projects in assembly language comes into play. There's only one *very* specific target here, certainly no build options to discover. And the entire project, including code, data and every tool needed fits easily in a self-contained ZIP file on the order of a megabyte or so, without the need for any installers or run-times.
Granted, that assumes the user is running Windows, but that's a safe enough bet.

Seriously. I have it down to the prospective artist unpacking a ZIP file and running a "build" batch file to rebuild the game. Unfortunately that also seems to be about maximum level of complexity I dare have without scaring people off.
A few more to the list:

ant / nant
msbuild
Visual Build
ClearMake
Rake
BuildIT
Maven


I'm sure Google can find some fairly comprehensive lists of build systems.
Though I've never tried it, I always thought the_edd's build system looked nice.

slam build system.
As far as I can tell CMake is the only proposed utility which is conveniently distributable as a single executable. Well.. Technically there's also the CRT DLLs but how hard can it be to reconfigure a cross-platform build tool to compile statically ;)

So I'll give it a try then, especially as it seems to be quite popular. Hopefully the scripting language is reasonably clean and expressive. Although given that it still produces Makefiles I'm a little worried that it won't insulate me completely from and/or be as powerful as Make (it will be interesting to see how it handles that problem with multiple targets during parallel gmake builds for one.)
Quote:Original post by theOcelot
Though I've never tried it, I always thought the_edd's build system looked nice.

slam build system.


It's fine for some things (static libs and executables), but I wouldn't recommend it here. I plan to retire it at some point in future (perhaps with a replacement, if I ever get around to it...)
IIRC there is a wiki page on this subject, if the wiki was working of course.
Personally I would add Premake to the list of suggestions. Also there have been a couple of threads on sweng gamedev on a related topic.
Quote:Original post by frob
ant / nant
msbuild
Visual Build
ClearMake
Rake
BuildIT
Maven


Please strike Maven off any such list of recommendations. It is practically inextensible, only suitable for Java, designed to conform projects to how it wants to do things rather than to adapt to user needs, and fundamentally incompatible with sound configuration control practices.

Chains of lots of custom tools are a very good fit for Ant, which has good facilities to manage lists of files and directories, a well refined "exec" task to invoke arbitrary command line tools, an explicit and readable dependency graph and parallel task invocations.
Ant needs a Java runtime environment and the large but trivial to install Ant tool itself; the former can be usually expected, the latter might be perhaps bundled with your sources.

I have significant experience using Ant with involved Java projects, and I've never had trouble getting it to do what I want without quirks; if assimilating command line tools isn't enough, there is the possibility of defining tasks as macros of other tasks, as embedded scripts in various languages or as Java classes based on a simple API, so adopting Ant isn't going to be a 90% solution.

Omae Wa Mou Shindeiru

This topic is closed to new replies.

Advertisement