Log for #openttdcoop.devzone on 28th May 2011:
Times are UTC Toggle Colours
00:23:01  *** KenjiE20 has quit IRC
06:53:59  *** andythenorth has joined #openttdcoop.devzone
07:04:23  <planetmaker> Yexo: thanks for that explanation. Yes, it makes sense to consider that carfully and postpone till there's something close to final
07:04:50  <planetmaker> thanks Rubidium for updating finger for opengfx
07:12:13  * andythenorth ponders
07:12:25  <andythenorth> buildout for FIRS might be an interesting learning project?
07:18:08  <planetmaker> might be. Though I'd recommend maybe not the most complicated but rather a simpler newgrf first ;-9
07:19:45  <andythenorth> hmm
07:19:58  <andythenorth> straight in at the deep end :)
07:21:09  <andythenorth> planetmaker: do any of your projects use nfo / grfcodec / nforenum?
07:22:29  <planetmaker> I guess not anymore. The snowlinemod one does, but it's superseeded by ogfx+landscape
07:24:32  <andythenorth> hmm
07:24:36  * andythenorth thinks
07:24:55  <planetmaker> well. my main project does: opengfx ;-)
07:25:41  <andythenorth> when you update newgrf makefile framework, do you then have to patch all projects using it?
07:27:41  <planetmaker> well... projects don't *need* to update. But yes, if they want the newest makefile, they have all to be patched
07:28:42  <planetmaker> but making the makefile an external dependency (do you try to hint at that?) is not entirely or not easily feasible
07:28:47  <andythenorth> I wondered
07:28:50  <planetmaker> the makefiles ARE the build system
07:29:07  <planetmaker> they describe how the newgrf is made
07:29:32  <andythenorth> are they specific to each project?
07:29:52  <planetmaker> I consider to modify it such that the non-specific parts could be integrated via a sub-repository approach
07:30:01  <planetmaker> but there are project-specific parts
07:30:24  <planetmaker> most notably Makefile.config and scripts/
07:30:40  <planetmaker> and possibly further scripts in well, scripts/*
07:31:08  <planetmaker> a makefile intrinsically has to be at somewhat project-specific
07:31:15  <planetmaker> as any build system
07:31:35  <andythenorth> are there significant common parts?
07:31:39  <planetmaker> yes, most
07:32:20  <planetmaker> <-- there are update and full packages
07:32:32  <planetmaker> the update packages contain mostly what is common to all projects
07:32:48  <planetmaker> The files they contain can be replaced by new versions usually without trouble
07:33:40  <andythenorth> interesting
07:33:52  <andythenorth> if we could figure it out, it could be a suitable use of buildout
07:34:00  <andythenorth> along with fetching nforenum and grfcodec
07:34:19  <andythenorth> although some might prefer a system-wide install of those tools, it's not strictly necessary...
07:34:33  <planetmaker> the makefile framework currently is not an external tool.
07:34:40  <planetmaker> Each project has all parts it needs
07:34:53  <planetmaker> and I'm not sure it *should* be externalized
07:34:59  <andythenorth> me neither :D
07:35:55  <planetmaker> Actually I don't think it should
07:36:06  <planetmaker> It should always remain part of a project's source
07:36:21  <andythenorth> I don't want to try and use buildout for the sake of it ;)
07:36:28  <planetmaker> as without it, a project has no _rules_ how to build.
07:36:38  <planetmaker> While grfcodec and nforenum are the _tools_
07:36:47  <andythenorth> I think it could be useful to minimise the setup time for someone who wants to checkout the grf + build or hack
07:37:09  <andythenorth> so the makefile remains part of the repo for the project in your view?
07:37:10  <planetmaker> Yes, so do I.
07:38:21  <planetmaker> yes, I think it does. Maybe it needs not, but I'd like to keep it so.
07:38:25  <planetmaker> For now.
07:39:04  <planetmaker> On the other hand, that's to a larger part because I don't quite yet see how in a reliable way it can be externalized
07:40:08  <planetmaker> *sometimes* changes to the makefile framework require adjustment in config files (which cannot be part of a common makefile framework). And then using a newer version of the makefile would break the whole thing - if not manual update of project-specific files is done at the same time, too.
07:40:15  <planetmaker> Thus automatic updates are dangerous
07:40:21  <planetmaker> And would mostly fall on my feet ;-)
07:40:35  <andythenorth> ok
07:41:31  <planetmaker> That's mainly why I currently prefer to have as much as possible in common (for easy updates) but still part of the projects (so that one change in the makefile doesn't break all projects)
07:42:25  <planetmaker> howevr, all this does not influence the use or not use of buildout
07:42:58  <planetmaker> the way to build a project will remain un-influenced... it will remain make, does it?
07:43:15  <planetmaker> just buildout makes for a convenient means to install all tools and deps, right?
07:43:21  <planetmaker> "just" ;-)
07:43:44  <andythenorth> yes
07:43:53  <andythenorth> buildout is not a good tool to build a grf
07:44:02  <planetmaker> why not?
07:44:16  <andythenorth> well - in this context you already have make working :)
07:44:33  <andythenorth> from a clean slate, buildout might be appropriate
07:44:49  <andythenorth> but we are where we are :)
07:45:05  <planetmaker> well... correct me if I didn't yet quite understand it: isn't buildout an easy-setup thing (mostly)?
07:45:21  <andythenorth> mostly
07:45:41  <planetmaker> how does it go beyond, how would it build a grf - assuming there was no makefile?
07:45:47  <andythenorth> I'm not sure
07:45:57  <andythenorth> I think you'd probably have to write a buildout recipe to do that
07:46:01  * andythenorth explores
07:46:17  <planetmaker> yes... and couldn't the recipie be 'call make'?
07:46:22  <andythenorth>
07:46:23  <Webster> Title: Buildout Recipes Buildout v1.2.1 documentation (at
07:46:28  <andythenorth> yes it could call make
07:46:47  <planetmaker> but maybe that's stupid, dunno
07:46:53  <andythenorth> ah - in this context there is a specific reason I think it's bad
07:47:04  <andythenorth> we use buildout to manage and setup the project environment
07:47:19  <andythenorth> but to get the grf built we don't need to check/update/rebuild the entire environment
07:47:25  <andythenorth> we could, but it's overkill
07:49:12  <planetmaker> I've not dived deeply into it. What I imagine: buildout installs mercurial / grfcodec / nforenum / make / gcc / ...
07:49:32  <andythenorth> it could install mercurial
07:49:43  <andythenorth> but usually you'd check out a project including buildout
07:49:48  <andythenorth> so that assumes mercurial
07:49:56  <planetmaker> hm, ho
07:49:57  <andythenorth> the buildout could be distributed as a zip
07:50:02  <andythenorth> and just run
07:50:39  <andythenorth> I think a buildout can even be packaged as a binary for each OS, although I'm not sure
07:52:00  <andythenorth> not sure if this one is useful or not:
07:52:01  <Webster> Title: Python Package Index : zc.recipe.cmmi 1.3.1 (at
07:52:54  *** frosch123 has joined #openttdcoop.devzone
07:53:42  <andythenorth> this might be the one to use to get grfcodec
07:53:43  <Webster> Title: Python Package Index : 1.3.0 (at
07:56:46  <planetmaker> well... I *think* buildout might be useful to make automatically available the required tools (nml, grfcodec, nforenum, gcc, make, gimp)
07:57:11  <andythenorth> I am exploring recipes...
07:57:29  <andythenorth> my level of buildout knowledge is only a little more than yours though
07:57:34  <planetmaker> maybe it is sensible to rewrite parts of the makefiles as buildout script. So maybe one can write a newgrf- generic buildout script
07:57:38  <andythenorth> my primary use is typing './bin/buildout'
07:58:01  <andythenorth> planetmaker: I'd start small and just have it fetch the tools / deps
07:58:12  <andythenorth> buildout is brilliant, but is an investment of time to setup
07:58:19  <andythenorth> replacing the makefile might be a step too far
07:58:54  <andythenorth> :)
07:59:04  <planetmaker> for one step: yes. In the long run. One will and can see
07:59:20  <planetmaker> Having a python-only build environment would be superior to the makefile
07:59:32  <planetmaker> It would be more portable and require less deps
07:59:42  <andythenorth> easier build for windows?
07:59:47  <planetmaker> yes. mostly
07:59:52  <andythenorth> ok
08:00:33  <andythenorth> hmm
08:00:53  <andythenorth> does it matter to have nml / nfo specific buildouts?  Maintaining two sounds like work
08:00:58  <planetmaker> but that transition will be quite lengthy to make sure things don't break ... the current makefiles can do quite a bit...
08:01:18  <planetmaker> that wouldn't matter too much. I have different makefile (parts) for nfo and nml, too
08:01:22  <andythenorth> fetching nml && grfcodec + nforenum seems to be no harm though
08:01:30  <andythenorth> especially if they're cached on your os
08:02:51  <planetmaker> the nml / nfo part is where, for example, the necessarily project-specific Makefile.config comes into play. nfo projects don't have scripts/makefile_nml and nml projects don't have scripts/makefile_nfo
08:03:19  <planetmaker> which each cover the specifics of nfo -> grf and nml->grf respectively
08:03:38  <andythenorth> ok
08:03:53  <andythenorth> this gives a useful insight into buildout:
08:03:54  <Webster> Title: Re: Understanding buildout - help please! : Mailing list archive : bzr-packagers team in Launchpad (at
08:11:36  <planetmaker> hm...
08:12:16  <planetmaker> andythenorth: what do I "get" (as in what files are generated) when you run bin/ on one of your projects?
08:13:52  <andythenorth> on FISH for example?
08:14:45  <planetmaker> fish.grf ?
08:15:27  <andythenorth> initially I'd say you get latest grfcodec and nforenum, probably in ./bin
08:15:39  <andythenorth> there aren't really other deps
08:15:48  <planetmaker> gcc, make
08:15:51  <andythenorth> oh yes
08:18:01  <Terkhen> hmm... those should be left out IMO
08:18:47  <Terkhen> they have packages on all linux distributions worthy of that name, they are always included in mingw (windows), I don't know about mac
08:19:53  <planetmaker> make has a bsd underlay. they're available
08:20:07  <planetmaker> s/make/mac/
08:30:38  <planetmaker> hm, Terkhen might be right. But adding the specifics to such buildout script might be a start. And teach us how it works
08:31:54  <Terkhen> I tested it for windows; it is quite simple to set up a building environment with it, but there is already an standalone nmlc.exe for download that (I guess) does the same thing
08:32:38  <andythenorth> planetmaker: lets see if we can figure out the simplest case
08:32:45  <planetmaker> agreed
08:32:52  <andythenorth> the simplest is either fetching nml or grfcodec/nforenum
08:42:15  * andythenorth assumes that fetching the compiled versions from bundles server might be the correct route
08:42:22  <andythenorth> building them locally seems unnecessary?
08:43:32  <Terkhen> IMO it is not needed
08:46:02  <planetmaker> building those locally would be quite beyond what is wanted. You'd need to require all their deps. Which are NOT light - weight.
08:53:30  <andythenorth> thought so
08:53:42  <andythenorth> so we 'just' need some recipe that fetches them?
08:53:51  <andythenorth> I am bad at path stuff
08:54:00  <andythenorth> the makefile will need to know where they are?
08:54:36  <planetmaker> maybe. it currently assumes they're available in the path
08:54:48  <planetmaker> you can explicitly tell to search elsewhere
08:55:36  <andythenorth> we'd need to do that I think
08:55:50  <andythenorth> using buildout to install to system might require sudo, which is a headache
08:56:40  <andythenorth> and it's generally the convention that buildout only works inside a certain dir
09:00:38  <andythenorth> planetmaker: where do I get grfcodec package?
09:00:48  <andythenorth> (I have been building it myself locally recently)
09:04:22  <andythenorth> hmm
09:04:25  <andythenorth> flaw in my plan
09:04:30  <andythenorth> grfcodec is OS specific
09:06:51  <Brot6> FIRS Industry Replacement Set - Revision 1995:5d176c40c53c: Change: quarry snow sprites changed (andythenorth) @
09:06:51  <Brot6> FIRS Industry Replacement Set - Revision 1996:a81779134f68: Change: work in progress adding snow ... (andythenorth) @
09:09:06  <planetmaker> hm... after I read quite a bit on the buildout site, I get the feeling it is mostly meant for python projects with (many) python modules
09:22:41  <andythenorth> planetmaker: it's certainly most commonly used for that case
09:22:58  <andythenorth> it can also build other things though
09:23:12  <andythenorth> it was trivial to fetch *a* version of grfcodec
09:23:24  <andythenorth> the problem I have is getting the right version for users OS
09:27:40  <planetmaker> hm.
09:30:05  <andythenorth> probably have to write our own recipe to check local OS
09:30:17  <andythenorth> or execute a local python script to do same
09:30:22  <andythenorth> (not much difference I think)
09:32:49  <planetmaker> uname is your friend there
09:33:11  <planetmaker> see scripts/Makefile.def for its use
09:33:26  <andythenorth> possibly this recipe might do it in that case:
09:33:27  <Webster> Title: Python Package Index : minitage.recipe.common 1.78 (at
09:41:58  *** andythenorth_ has joined #openttdcoop.devzone
09:49:29  *** andythenorth has quit IRC
10:02:32  *** ODM has joined #openttdcoop.devzone
11:06:30  *** KenjiE20 has joined #openttdcoop.devzone
12:16:41  <Brot6> OpenGFX+ Industries - Bug #2666 (New): <invalid cargo> produced at tropical frams (Hirundo) @
14:42:04  <planetmaker> :-(
14:42:46  <Terkhen> oh, true, I confirmed it while we played but forgot to comment about it :P
14:42:55  <Terkhen> it does not happen when the cargo is explicitly set
14:43:14  <Terkhen> so it is probably a condition not initialized properly
14:52:46  *** andythenorth has joined #openttdcoop.devzone
14:59:47  *** andythenorth_ has quit IRC
15:05:42  <Brot6> Swedish Rails - Bug #2570: support for opengfx+landscape (planetmaker) @
15:18:29  *** andythenorth_ has joined #openttdcoop.devzone
15:18:57  *** andythenorth__ has joined #openttdcoop.devzone
15:18:59  *** andythenorth has quit IRC
15:26:30  *** andythenorth_ has quit IRC
15:32:59  <Brot6> Swedish Rails - Bug #2570: support for opengfx+landscape (V453000) @
15:33:44  <V453000> DJNekkid: the 1.1.0 nutracks look really terrible :( no offence
15:34:06  <planetmaker> V453000: complain to oberhuemer ;-)
15:34:35  <V453000> not here :)
15:52:31  <Brot6> World Airliners Set - Revision 672:200580745cab: update to add new liveries (FaddyPainter) @
17:18:44  <Brot6> firs: update from r1994 to r1996 done -
17:19:43  <Brot6> worldairlinersset: update from r671 to r672 done -
17:19:43  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r90), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), fish (r648), frenchtowns (r6), german-townnames (r34), grfcodec (r829), grfpack (r279), heqs (r605),
17:19:44  <Brot6> indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (ERROR r293), nml (r1359), nutracks (r201), ogfx-industries (r107), ogfx-landscape (r68), ogfx-rv (r107), ogfx-rv.clone (r103), ogfx-trains (r241), ogfx-trees (r48), opengfx (r673), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns
17:19:50  <Brot6> (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36)
17:20:28  <Brot6> OpenGFX+ Airports - Bug #2667 (New): DevZone compile failed (compiler) @
17:20:57  <Brot6> Belarusian Town Names - Bug #2668 (New): DevZone compile failed (compiler) @
17:20:57  <Brot6> French Town Names - Bug #2669 (New): DevZone compile failed (compiler) @
17:21:50  <Brot6> German town names - Bug #2670 (New): DevZone compile failed (compiler) @
17:21:50  <Brot6> Indonesian Town Names - Bug #2671 (New): DevZone compile failed (compiler) @
17:21:50  <Brot6> Manual Industries - Bug #2672 (New): DevZone compile failed (compiler) @
17:21:50  <Brot6> North American Road Vehicle Set - Bug #2673 (New): DevZone compile failed (compiler) @
17:21:52  <Brot6> newgrf_makefile: compile of r293 still failed (#2656) -
17:22:51  <Brot6> OpenGFX+ Industries - Bug #2674 (New): DevZone compile failed (compiler) @
17:22:51  <Brot6> OpenGFX+ Landscape - Bug #2675 (New): DevZone compile failed (compiler) @
17:23:25  <Terkhen> nice
17:23:43  <Brot6> OpenGFX+ Road Vehicles - Bug #2676 (New): DevZone compile failed (compiler) @
17:24:02  <Terkhen> the error is quite strange
17:24:43  <Brot6> ogfx-rv.clone: compile of r103 failed -
17:25:20  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:25:47  <Brot6> OpenGFX+ Trains - Bug #2677 (New): DevZone compile failed (compiler) @
17:25:47  <Brot6> Spanish Town Names - Bug #2678 (New): DevZone compile failed (compiler) @
17:26:05  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:26:54  <Brot6> Swedish Rails - Bug #2679 (New): DevZone compile failed (compiler) @
17:26:54  <Brot6> Swiss Town Names - Bug #2680 (New): DevZone compile failed (compiler) @
17:27:15  <Ammler> andythenorth__: could help
17:28:39  <Ammler> the problem is rather that building failed because nml didn't make a proper release
17:29:08  <Ammler> and the question is how to test that
17:30:06  <Ammler> we should not make a error bundle on rebuilds
17:33:49  <Ammler> hmm, no idea
17:35:26  <Ammler> it is impossible to determine, if building fails because of faulty package
17:53:03  <Ammler> what we could do is reporting rebuild errors to the packages triggered the rebuild
17:59:10  <Brot6> OpenGFX+ Industries - Bug #2666 (New): <invalid cargo> produced at tropical frams (Hirundo) @
17:59:10  <Brot6> Swedish Rails - Bug #2570: support for opengfx+landscape (planetmaker) @
17:59:10  <Brot6> Swedish Rails - Bug #2570: support for opengfx+landscape (V453000) @
18:56:15  *** andythenorth__ has quit IRC
18:58:44  *** andythenorth has joined #openttdcoop.devzone
19:54:32  <V453000> DJNekkid: would it be considerable to make nutracks have not only configurable track speeds, but also date when they come out? Would be greatly helpful
20:07:32  <Yexo> @seen DJNekkid
20:07:32  <Webster> Yexo: DJNekkid was last seen in #openttdcoop.devzone 10 weeks, 1 day, 21 hours, 22 minutes, and 0 seconds ago: <DJNekkid> for example, the IC pax wagons will be a combination of 2nd class, 1st class, diner and sleeper
20:07:44  <Yexo> V453000: better ask the new coder for nutracks ;)
20:08:44  <V453000> who that is? :o
20:09:17  <Rubidium> oberhuemer (can't be bothere to find the umlaut)
20:09:46  <Yexo> ^^ indeed, I couldn't remember
20:21:11  <V453000> :( why isnt he on the devzone
20:21:18  <V453000> or ... here in the channel :)
20:31:26  <Brot6> Manual Industries - Bug #2672 (Rejected): DevZone compile failed (compiler) @
20:31:26  <Brot6> Manual Industries - Bug #2672 (Rejected): DevZone compile failed (frosch) @
21:28:30  *** andythenorth has quit IRC
21:53:21  <Ammler> Yexo: did you notice the nml setup error?
21:57:40  <Brot6> NewGRF Meta Language - Bug #2681 (New): setup error (Ammler) @
22:00:18  <Ammler> nmlc looks quite different
22:02:27  <Ammler>
22:03:04  <Ammler> or should we use another setup?
22:03:31  *** ODM has quit IRC
22:04:00  *** frosch123 has quit IRC
22:08:04  <Ammler> V453000: as said, you should post it on forums or else a ticket
22:08:15  <Ammler> obverh├╝mer is never here
22:09:12  <Ammler> @seen oberh*
22:09:12  <Webster> Ammler: oberhuemer was last seen in #openttdcoop.devzone 14 weeks, 4 days, 21 hours, 14 minutes, and 2 seconds ago: <oberhuemer> I have a question. I've set up the NARVS to build on push, but it looks like it doesn't do it every time. Are there restrictions?
23:46:18  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk