News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Makefiles (was: MOSE)

Started by wlindley, February 25, 2010, 11:19:29 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

wlindley

Why would you write a whole new tool, instead of using GNU 'make' -- www.gnu.org/software/make/ -- which takes care of defining variables, examining dependency trees, and running all programs... and is standard on any modern system?

(not being argumentative, just curious)

VS

Here's your answer:
QuoteC:\Documents and Settings\Vladimir>make
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

wlindley

Don't use Borland make.  Use GNU make.  GNU make is GPL'd, has been for a decade at least.

http://gnuwin32.sourceforge.net/packages/make.htm

VS

Then it's a question of installing make versus installing Python. As I'm on windows, the choice is size vs. fiddling with PATH.

If you want to start tearing your hair out, pak128 also uses its own tool.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

wlindley

So I see, pak128 has a custom tool.  I've read through it and it seems to be rewriting GNU make...

pak64 uses a regular Makefile, which works perfectly... why re-invent the wheel?

I will be using pak64's build model in pak128.USA

VS

For one, about every genial developer had the great idea that "make" is a name free to take, so I have a lot of makes around, each of them needed by something (my previous post is just a preview :P ). Secondly, even with GNU make the pak64 makefile does not work perfectly around here. Looks like MAKEOBJ ?= ./makeobj makes it *nix-specific, not to mention rm and cp and all that. So... sorry, but this just doesn't cut it for me. Also there is no good recursion, which I prefer to all the folders listed in one place. The few hours I spent writing that one script in Python can be hardly compared with the 20+ years of make, yet my script runs on two major os cores just fine... what can I fix by switching?

QuoteD:\Hry\Simutrans\DEV\64svn>mingw32-make
"===> COPY"
Nesprávná syntaxe příkazu
mingw32-make: *** [copy] Error 1

D:\Hry\Simutrans\DEV\64svn>mingw32-make zip
mingw32-make: *** No rule to make target `simutrans/pak', needed by `simupak64.zip'.  Stop.

D:\Hry\Simutrans\DEV\64svn>mingw32-make tar
mingw32-make: *** No rule to make target `simutrans/pak', needed by `simupak64.tbz2'.  Stop.

D:\Hry\Simutrans\DEV\64svn>mingw32-make clean
"===> CLEAN"

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Michael 'Cruzer'

MOSE is developed cause it works on EVERY platform, without changing anything (Like / or \) and if you use it correctly you also don't need it to configure... (and also has a small kind of special functions...)
Of course you could use GNU make or any other build tool! But it's the descision of the pakset leader what's to use. And for pak128, pak128.britain and pak192.comic it's a own python script.
Founder and Ex-Maintainer of pak192.comic. Provider of Simutrans Hosting rental service.

prissi

To compile simutrans one needs anyway mingw on Windows back when MSVC was unusable due to variable lifetimes etc. (version 6 and earlier). In that age pak64 was the only one in existence and was also built by the same make. And on all other platforms one needs GNU make to compile simutrans anyway.

This (and the non-existence of python in the public) was the reason why pak64 uses pak.