UFO:Alien Invasion
Development => Coding => Topic started by: Doctor J on March 28, 2008, 10:43:28 pm
-
I'm finding that 'make clean/make/make lang' is almost inconsequential in terms of time needed, but 'make maps' takes so long that i essentially have to plan around it. Therefore i would like to offer the following suggestions:
- pre map: output the total number of maps needed to be remade
- post map: output the total amount of time used making maps
-
Surely you can do that by editing the makefile a bit?
-
Does the Makefile even check to see whether a compiled map already exists before running? I didn't notice that it does. And to find out how much time it took, just type 'time make maps'. If you're running a multi core/processor setup you might also want to enable parallel compiles with 'make -j maps'. 'time make -j maps' does both at once, and if you want to be compiling maps and still be able to do things without having your computer as laggy as 1400 baud, prefix it with 'nice -n 10', to put it on a lower priority: 'nice -n 10 time make -j maps' if you're getting everything on your hotdog. Note that though you can pass both nice and time simultaneously, it's useless for benchmarking.
-
Of course make checks to see if a map exists when you run it. That's kind of what make is all about. Try running a make maps and then make maps again. The second time it'll tell you there's nothing to be done.
-
Does the Makefile even check to see whether a compiled map already exists before running?
The 2.3-dev version has only recently just added a -onlynewer flag for mapmaking, so i'm pretty sure that other versions do make all maps from scratch.
prefix it with 'nice -n 10'
Erm, the makefile already sets nice 19. Look at trunk/build/maps.mk.
-
The 2.3-dev version has only recently just added a -onlynewer flag for mapmaking, so i'm pretty sure that other versions do make all maps from scratch.
Well, MY make (on Windows) sure skips maps that don't need recompiling, and I run it without any arguments whatsoever.
-
Well, MY make (on Windows) sure skips maps that don't need recompiling, and I run it without any arguments whatsoever.
That is the beauty of make. It only invokes the rule if the target predates the dependencies. Of course you know that... ;)
ponkan, the Makefile does not explicitly check for out of date files. The magic is in the compile rule:
$(BSPS): %.bsp: %.map
$(UFO2MAP) $(UFO2MAPFLAGS) $<
The first line says that every required BSP file depends on a MAP file with the same name. If the MAP file is newer than the BSP file or the BSP file doesn't exist, then invoke the following set of indented commands, which in this case calls ufo2map.
This is all very basic make usage - it really is worth your time to learn this stuff. It will make your life as a developer much better.
-
My comment on nice was based on behavior I noticed in 2.2.1, ran make -j and I couldn't get anything done.
Thanks for the lesson. I'm afraid all my knowledge is self-taught, and I'm just beginning to compile my own packages. Make is still mostly arcane to me, I'm usually able to figure out what the Makefile targets do, but some of the syntax is just way over my head.
-
Yeah, make is a bit arcane. Most prehistoric bits of software are ;D I think that pretty much every new software developer has recoiled in shock at their first introduction to make. However, the old hats usually end up on the love side of the love-hate relationship we all have with make. Most of the hate comes from keeping the dependencies up to date (which is why after svn up I always use make clean before make).
Thankfully, there are many, many examples out there, and GNU has quite good documentation. I would say that learning make has been more useful to me than learning anything about gcc.
-
Of course the main project could have the 'made' maps committed to it and have an originals/ project for the map sources, that way the only person who needs to 'make' a map is the map author. But that'd just save a lot of time and energy for everybody involved. ::) Yeah I know, you're not interested... ::)
-
Actually, you have an excellent point, at least when it come to releases. It would probably be a good idea to archive the released maps in the point releases (i.e. in the tags branch). That way there would be a definitive version for each release, and it would save many people who want to compile the releases themselves (like package maintainers, etc.)
-
I know I have an excellent point, hence I'm bringing it up *again*. Sadly I failed to convey this to the decision makers the last time (http://ufoai.ninex.info/forum/index.php?topic=1872.0) I tried.
-
The magic is in the compile rule:
So what, please, does '-onlynewer' flag to ufo2map actually do? I'm not being ironic - i really don't know!
-
erm
it ONLY compiles it, if the .map is NEWER than the .bsp
-
Of course, -onlynewer really only makes sense outside the context of make, or if the target depends on something like .PHONY (which it doesn't.) If you are using make maps then that option is redundant since make will only call ufo2map if the map file is newer than the bsp.
-
I don't think ufo2map actually supports wildcards in its arguments, does it? Otherwise you could do something like
ufo2map base/maps/*.map -onlynewerand it'd be essentially the same as make maps. Except it'd have to be recursive too. And it wouldn't skip the prefabs.
-
Oh, you could also run
find base/maps -name *.map -exec ufo2map -onlynewer {} \;
but only if you are using something smart enough to support find.