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/Makefile.in 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> http://bundles.openttdcoop.org/newgrf_makefile/releases/LATEST/ <-- 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> http://www.buildout.org/docs/recipelist.html 07:46:23 <Webster> Title: Buildout Recipes Buildout v1.2.1 documentation (at www.buildout.org) 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: http://pypi.python.org/pypi/zc.recipe.cmmi/1.3.1 07:52:01 <Webster> Title: Python Package Index : zc.recipe.cmmi 1.3.1 (at pypi.python.org) 07:52:54 *** frosch123 has joined #openttdcoop.devzone 07:53:42 <andythenorth> this might be the one to use to get grfcodec http://pypi.python.org/pypi/hexagonit.recipe.download/1.3.0 07:53:43 <Webster> Title: Python Package Index : hexagonit.recipe.download 1.3.0 (at pypi.python.org) 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: https://lists.launchpad.net/bzr-packagers/msg00031.html 08:03:54 <Webster> Title: Re: Understanding buildout - help please! : Mailing list archive : bzr-packagers team in Launchpad (at lists.launchpad.net) 08:11:36 <planetmaker> hm... 08:12:16 <planetmaker> andythenorth: what do I "get" (as in what files are generated) when you run bin/buildout.py 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5d176c40c53c 09:06:51 <Brot6> FIRS Industry Replacement Set - Revision 1996:a81779134f68: Change: work in progress adding snow ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/a81779134f68 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: http://pypi.python.org/pypi/minitage.recipe.common/1.78#notes 09:33:27 <Webster> Title: Python Package Index : minitage.recipe.common 1.78 (at pypi.python.org) 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) @ http://dev.openttdcoop.org/issues/2666 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) @ http://dev.openttdcoop.org/issues/2570#change-6764 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) @ http://dev.openttdcoop.org/issues/2570#change-6765 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) @ http://dev.openttdcoop.org/projects/worldairlinersset/repository/revisions/200580745cab 17:18:44 <Brot6> firs: update from r1994 to r1996 done - http://bundles.openttdcoop.org/firs/nightlies/r1996 17:19:43 <Brot6> worldairlinersset: update from r671 to r672 done - http://bundles.openttdcoop.org/worldairlinersset/nightlies/r672 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) @ http://dev.openttdcoop.org/issues/2667 17:20:57 <Brot6> Belarusian Town Names - Bug #2668 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2668 17:20:57 <Brot6> French Town Names - Bug #2669 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2669 17:21:50 <Brot6> German town names - Bug #2670 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2670 17:21:50 <Brot6> Indonesian Town Names - Bug #2671 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2671 17:21:50 <Brot6> Manual Industries - Bug #2672 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2672 17:21:50 <Brot6> North American Road Vehicle Set - Bug #2673 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2673 17:21:52 <Brot6> newgrf_makefile: compile of r293 still failed (#2656) - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r293 17:22:51 <Brot6> OpenGFX+ Industries - Bug #2674 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2674 17:22:51 <Brot6> OpenGFX+ Landscape - Bug #2675 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2675 17:23:25 <Terkhen> nice 17:23:43 <Brot6> OpenGFX+ Road Vehicles - Bug #2676 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2676 17:24:02 <Terkhen> the error is quite strange 17:24:43 <Brot6> ogfx-rv.clone: compile of r103 failed - http://bundles.openttdcoop.org/ogfx-rv.clone/nightlies/ERROR/r103 17:25:20 <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66 17:25:47 <Brot6> OpenGFX+ Trains - Bug #2677 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2677 17:25:47 <Brot6> Spanish Town Names - Bug #2678 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2678 17:26:05 <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666 17:26:54 <Brot6> Swedish Rails - Bug #2679 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2679 17:26:54 <Brot6> Swiss Town Names - Bug #2680 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2680 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) @ http://dev.openttdcoop.org/issues/2666 17:59:10 <Brot6> Swedish Rails - Bug #2570: support for opengfx+landscape (planetmaker) @ http://dev.openttdcoop.org/issues/2570#change-6764 17:59:10 <Brot6> Swedish Rails - Bug #2570: support for opengfx+landscape (V453000) @ http://dev.openttdcoop.org/issues/2570#change-6765 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) @ http://dev.openttdcoop.org/issues/2672 20:31:26 <Brot6> Manual Industries - Bug #2672 (Rejected): DevZone compile failed (frosch) @ http://dev.openttdcoop.org/issues/2672#change-6766 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) @ http://dev.openttdcoop.org/issues/2681 22:00:18 <Ammler> nmlc looks quite different 22:02:27 <Ammler> http://paste.openttdcoop.org/show/234/ 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