Config
Log for #openttdcoop.devzone on 15th June 2011:
Times are UTC Toggle Colours
05:08:13  *** andythenorth has joined #openttdcoop.devzone
05:20:23  <Brot6> FIRS Industry Replacement Set - Feature #2742 (New): Farms - location hint needed in fund menu (andythenorth) @ http://dev.openttdcoop.org/issues/2742
05:32:26  <Brot6> FIRS Industry Replacement Set - Revision 2052:32cdd642bb04: Change: add snow framework to Sheep Farm (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/32cdd642bb04
05:41:17  *** bodis has quit IRC
05:51:17  <Brot6> FIRS Industry Replacement Set - Revision 2053:73d2f508eb8a: Change: snow framework for Lime Kiln (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/73d2f508eb8a
05:51:17  <Brot6> FIRS Industry Replacement Set - Revision 2054:ee71b0f63ce1: Change: snow framework for Machine Shop (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ee71b0f63ce1
06:09:17  <Brot6> FIRS Industry Replacement Set - Feature #2743 (New): Add building tile to Oil Wells (andythenorth) @ http://dev.openttdcoop.org/issues/2743
06:18:54  <Brot6> FIRS Industry Replacement Set - Feature #2743 (Closed): Add building tile to Oil Wells (andythenorth) @ http://dev.openttdcoop.org/issues/2743
06:18:54  <Brot6> FIRS Industry Replacement Set - Revision 2055:d88e59ff879c: Change: add building to Oil Well (clo... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d88e59ff879c
06:18:54  <Brot6> FIRS Industry Replacement Set - Feature #2743 (Closed): Add building tile to Oil Wells (andythenorth) @ http://dev.openttdcoop.org/issues/2743#change-6884
06:39:05  <Brot6> FIRS Industry Replacement Set - Revision 2056:dd6449b8b98a: Feature: additional layout for Sheep ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/dd6449b8b98a
06:51:35  *** andythenorth is now known as Guest4656
06:51:36  *** andythenorth has joined #openttdcoop.devzone
06:57:27  *** Guest4656 has quit IRC
09:03:26  *** andythenorth has quit IRC
09:04:18  *** andythenorth has joined #openttdcoop.devzone
09:13:11  *** Tloo-ZaRaZa has joined #openttdcoop.devzone
12:46:07  *** Tloo-ZaRaZa has quit IRC
12:49:20  <Brot6> NewGRF Meta Language - Revision 1405:b5baff8c855f: Fix: 'tons' was not recognized as valid unit, ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b5baff8c855f
12:49:55  <Ammler> planetmaker: would opengfx nml parts be buildable with nml release versions?
12:49:59  <Ammler> (always)
12:50:13  <planetmaker> hm... I did not think about that
12:50:18  <planetmaker> probably should
12:50:36  <planetmaker> though it doesn't matter for nightlies
12:50:51  <Ammler> ah well, I ask for suse rpm
12:51:20  <Yexo> Ammler: no, not always
12:51:29  <Yexo> since they might start using new features introduced in newer nml versions
12:51:40  <Ammler> Yexo: well, that is the question
12:52:10  <Ammler> we could disallow opengfx nml to use unreleased features
12:52:11  <Yexo> take only ogfx+airports for example, there already is a diff to add the fences, but current nml doesn't support that
12:52:14  <planetmaker> releases must work with released NML
12:52:22  <planetmaker> Yexo: OpenGFX. Not newgrfs
12:52:36  <Yexo> oh, opengfx, I thought all ogfx+ newgrfs
12:52:47  <Yexo> in that case, staying with nml release versions should be fine :)
12:53:07  <Ammler> nah, just for distro packages, currently opengfx is and will be in the near future the only grf
12:55:52  <Ammler> planetmaker: current opengfx still needs additional target to make nfo from nml, right?
12:56:02  <planetmaker> yes
12:56:22  <Ammler> would it make sense to add that for testing purposes already?
12:56:30  <Ammler> or shall we wait until you change that
12:57:16  <planetmaker> it would make sense to add that for testing purposes, yes
12:57:34  <planetmaker> though... hm... maybe it should be used straight away.
12:57:40  <planetmaker> is NML in the build requirements?
12:58:30  <Ammler> not yet
12:58:45  <Ammler> that is why I brought up this question :-P
12:59:12  <Ammler> opengfx has own build config anyway...
13:15:31  <Ammler> not a target, rather USE_NML2NFO=1
13:26:16  <Ammler> planetmaker: is it enough to just use USE_NML2NFO=1 with make or shall I somehow clean the nfos first? (maintainer-clean or so)
13:27:18  <planetmaker> that *should* be enough
13:27:56  <planetmaker> hopefully
13:29:21  <Ammler> then push
13:30:08  <Brot6> OpenGFX - Revision 674:6023526bf54b: Change: add nml2nfo to the buildsystem (will use nml releases) (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/6023526bf54b
13:32:04  <Ammler> so we have also a package, which does test nml releases :-)
14:32:41  *** Tloo-ZaRaZa has joined #openttdcoop.devzone
14:43:11  *** andythenorth has quit IRC
14:55:25  *** Tloo-ZaRaZa has quit IRC
15:12:19  <Terkhen> I have made a script that grabs all special words from nml source and splits them in two groups (for creating syntax highlighters)
15:12:30  <Terkhen> besides creating a syntax highlighter for myself, what should I do with the script? :P
15:12:37  <Terkhen> (it is quite hacky though)
15:12:48  *** ODM has joined #openttdcoop.devzone
15:13:14  <Ammler> well, you can always add it to the tracker
15:13:53  <Terkhen> a new project?
15:14:10  <Ammler> I meant to the nml tracker
15:14:54  <Terkhen> but it is not part of nml, it should remain standalone IMO
15:17:34  *** andythenorth has joined #openttdcoop.devzone
15:44:24  *** Lakie has joined #openttdcoop.devzone
16:08:41  *** frosch123 has joined #openttdcoop.devzone
16:11:02  <Yexo> frosch123: if using your extended sprite layout, can you reference sprites from another action1 set?
16:11:18  <frosch123> no
16:11:20  <andythenorth> is there new documentation for it yet?
16:11:23  <andythenorth> I have use cases :)
16:11:28  <frosch123> well, for stations you can
16:13:20  <frosch123> i don't see how it could be done for stuff with the spritelayout in the action2
16:13:56  <Yexo> set bit 1, add offset to sprite, and make the offset bigger than the action1 set you're referencing
16:14:05  <Yexo> mind you, not a different action1, just another set inside the same action1
16:14:21  <frosch123> oh, that
16:14:26  <frosch123> well, yes, that would work
16:14:31  <frosch123> though not officially :)
16:14:41  <Yexo> I was wondering about that
16:14:54  <frosch123> but you can also archieve that by skipping sprites
16:15:01  <Yexo> I assumed first that it wasn't, but Hirundo checked the code and said it would work
16:15:08  <Yexo> skipping sprites?
16:15:26  <frosch123> you can specify a register to not draw a sprite at all
16:15:39  <Yexo> ah, that
16:16:17  <Yexo> I was more thinking off a case like this: say I have 16 different groundsprites, but only a single building sprite
16:16:24  <Yexo> all sprites are in the action1
16:16:30  <Ammler> Terkhen: not everything on the tracker needs to be included in the repo, imo
16:16:54  <Yexo> if I were to use the extended spritelayout to select the proper groundsprite and they would have to be in one set, I'd waste 15 empty sprites for the 'building' sprite set
16:16:56  <frosch123> Yexo: then you would add 15 dummy sprites
16:16:58  <planetmaker> Ammler: Terkhen a good place might be the DevZone's general file section
16:17:05  <Terkhen> Ammler: sorry, I thought you meant the repo :)
16:17:06  <Ammler> if it is something advanced, feel free to make a subproject and
16:17:13  <Yexo> instead I could opt for 17 spritesets and pick one of them
16:17:25  <Ammler> planetmaker: general file section?
16:17:31  <Yexo> but if I understand you correctly that is not officially supported, it will work though
16:17:33  <frosch123> Yexo: anyway, that looks rather like it would need a new action1
16:17:41  <frosch123> with variable amount of sprites in a set
16:17:49  <planetmaker> hm... I thought the #openttdcoop "project" had a documents / files tab
16:18:03  <Ammler> planetmaker: it is for nml only
16:18:15  <frosch123> Yexo: well, all sprites in an action1 are loaded sequentially and get continuous sprite numbers
16:18:31  <Yexo> yes, if that were documented it would be fine :)
16:18:37  <Ammler> well, important is to publish it somewhere :-P
16:19:04  <planetmaker> Ammler: http://dev.openttdcoop.org/projects/grf-tools/settings <-- what about adding one there?
16:19:20  <Ammler> planetmaker: as said, it is nml only
16:19:37  <Ammler> I don't really care :-)
16:19:39  <frosch123> Yexo: it does not feel right to document that :)
16:19:40  <Yexo> frosch123: or should I use bit 6 in that case and make two different action1's?
16:19:50  <Yexo> that sounds better, though I do not know how that would work
16:19:56  <Yexo> what happens exactly if you use bit 6?
16:19:57  <planetmaker> right... http://dev.openttdcoop.org/projects/nml/files <-- Terkhen
16:20:17  <frosch123> [18:19] <Yexo> frosch123: or should I use bit 6 in that case and make two different action1's? <- for stations? yes, definitely
16:20:20  <Ammler> why not tracker, then you can also comment it a bit :-P
16:20:21  <Terkhen> ok
16:20:26  <Ammler> or wiki or documents
16:20:31  <Yexo> frosch123: and if it were for industry tiles?
16:20:33  *** bodis has joined #openttdcoop.devzone
16:20:35  <Ammler> but files is well...
16:20:40  <frosch123> bit 6+7 only work for stations
16:20:42  <Ammler> just files
16:20:52  <Yexo> ok :)
16:21:06  <Terkhen> http://dev.openttdcoop.org/documents/24 <--- the other one was in a document, but this is a script so I was not sure
16:21:22  <frosch123> for action2 spritelayouts: i could imagine to change the behaviour of action1 into a push:_front
16:21:52  <Yexo> and that means?
16:21:54  <planetmaker> I don't care, Terkhen. If the other is there, maybe go there, too
16:22:01  <frosch123> i.e. if you have one action1 with spritesets A, B, C, and then a second action1 with spritesets D, E: they would result in D, E, A, B, C
16:22:04  <planetmaker> I didn't know the other was there :-)
16:22:10  <frosch123> so you can still access sprites from earlier action1
16:22:15  <Yexo> ah, that makes sense
16:22:16  <planetmaker> documents might make more sense actually
16:22:18  <frosch123> that would work for action2 spritelayouts
16:22:29  <frosch123> but not for vehicles and stations
16:23:00  <planetmaker> I always confuse files and documents ;-) - I meant to say that here
16:23:16  <Yexo> hmm, why not for vehicles?
16:23:54  <frosch123> for action2 spritelayouts the first sprite of the spriteset to use is resolved on loading in newgrf.cpp
16:24:36  <frosch123> hmm...
16:24:40  <frosch123> maybe you are right
16:25:21  <frosch123> but we would need to store the used spritesets in the RealSpriteGroup
16:26:31  <frosch123> hmm, maybe we already do that :o
16:26:45  <Yexo> ResultSpriteGroup stores the SpriteID
16:27:03  <frosch123> yes, i thought it would only store the first sprite of the action1, and the set
16:27:48  <frosch123> so, i guess the action1-push_front could be a nice feature :)
16:27:49  <Yexo> it stores the spriteid (index in openttd pool) and number of sprite in that group
16:27:57  <Yexo> however other groups could have different sizes
16:28:19  <Yexo> so while sprite+num_sprites points to the prev group, you cannot go further than that
16:28:34  <frosch123> well, important is that RealSpriteGroup has an array of spritenumbers for every set
16:28:55  <Yexo> ah, that
16:29:28  <Yexo> if the action1-push_front would be seperate for each feature that would be even better :)
16:31:04  <frosch123> :)
16:36:28  *** Tloo-ZaRaZa has joined #openttdcoop.devzone
16:59:24  *** Tloo-ZaRaZa has quit IRC
17:10:14  <Brot6> nml: update from r1404 to r1405 done - http://bundles.openttdcoop.org/nml/nightlies/r1405
17:18:44  <Brot6> firs: update from r2048 to r2056 done - http://bundles.openttdcoop.org/firs/nightlies/r2056
17:20:25  <Brot6> opengfx: update from r673 to r674 done - http://bundles.openttdcoop.org/opengfx/nightlies/r674
17:20:34  <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 (r93), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec (r831), grfpack (r279), heqs (r605),
17:20:34  <Brot6> indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r294), nml (r1405), nutracks (r202), ogfx-industries (r119), ogfx-landscape (r69), ogfx-rv (r107), ogfx-trains (r242), ogfx-trees (r50), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34),
17:20:36  <Brot6> ttrs (r36), worldairlinersset (r672)
17:23:33  <Ammler> planetmaker: didn't work :'-(
17:23:39  <Ammler> installing nml-0.1.0-suse1130
17:24:01  <Ammler> make -j1 docs USE_NML2NFO=1 UNIX2DOS=
17:24:23  <Ammler> but the build log is without: http://bundles.openttdcoop.org/opengfx/nightlies/r674/log/opengfx-r674-build.log
17:24:27  <Ammler> or do I miss something?
17:24:53  <Ammler> how do you detect nmlc?
17:26:29  <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66
17:27:17  <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666
17:28:04  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus (Diffsize: 12), belarusiantowns (Diffsize: 30), frenchtowns, german-townnames, indonesiantowns (1 errors) (Diffsize: 1), manindu (Diffsize: 1), narvs, newgrf_makefile, ogfx-industries, ogfx-landscape (Diffsize: 21), ogfx-rv, ogfx-trains, spanishtowns (Diffsize: 1), swedishrails (Diffsize: 385), swisstowns
17:54:08  <Ammler> this is very silly
17:54:40  <Ammler> make USE_NML2NFO=1 works locally but not on the server, any clue?
17:57:35  <frosch123> http://wiki.openttd.org/Frosch/Extended_Action_1 <- Yexo: i think the push_front is actually a bad idea. instead there should just be an index for the first spriteset to define with an action1
17:58:13  <Yexo> reading it now
17:58:30  <planetmaker> Ammler: I guess it didn't use NML there as the files are of the same age. The NML files are not newer than the pnfo files, rather older
17:58:48  <planetmaker> As both are part of the repo, the pnfo files are already 'up to date', thus not re-build
18:00:19  <Yexo> Shall the new format enforce not mixing Action 1 of different features? (this might actually be a disadvantage for common ground sprites)  <- yes please
18:00:33  <Yexo> I don't see any advantage in that at ll
18:00:53  <Yexo> as there are (almost) no cases where a single grf should use a sprite for multiple features
18:01:25  <frosch123> mostly groundsprites
18:01:41  <planetmaker> ^
18:01:44  <Yexo> but imo a grf that wants to define multiple features that use groundsprites should be split
18:01:45  <frosch123> what is the advantage of separating them?
18:02:22  <Yexo> the feature that use groudsprites are: stations, houses, industry tiles, airport tiles, objects
18:02:38  <Yexo> perhaps objects + some other feature belong together
18:03:03  <Yexo> on the other hand I doubt there will be any harm in not forbidding to share the sprites between features
18:03:03  <planetmaker> and landscape... but that's not a feature
18:04:43  <Yexo> frosch123: I like that proposal :)
18:05:06  <Yexo> should <first-spriteset> really be an extended byte?
18:05:08  <planetmaker> what about stations and airports?
18:05:18  <Yexo> planetmaker: stations can already do this
18:05:29  <planetmaker> I mean in one grf
18:05:37  <Yexo> oh, perhaps
18:07:16  <Yexo> frosch123: I was thinking if you limitted it to spritesets 0..255, you could do away with the std::map<> and just use an expanding array like so many others in newgrf.cpp
18:07:32  <Yexo> however your current proposal is a bit more flexible
18:07:38  <planetmaker> but indeed I don't have a strong opinion there one way or another
18:07:45  <frosch123> we can also enforce the not-mix-features, and add a special feature FF which makes the action 1 apply to all features
18:08:14  <Yexo> in that case everyone could start defining all action1's as FF, just to avoid any errors
18:08:25  <Yexo> so we might as well just allow it
18:08:34  <frosch123> Yexo: action2 spritelayouts have 14 bits for referencing an action1 set
18:08:39  <frosch123> so, we should allow setting them
18:08:57  <Yexo> so why is <num-sets> still a byte?
18:09:06  <Yexo> if you make a new format, you could make that an extended byte as well
18:09:09  <frosch123> in case someone defined FF sets?
18:09:17  <Yexo> just for the new format
18:09:17  <frosch123> oh, true
18:10:04  <frosch123> fixed
18:15:45  <Yexo> I do not see an alternative to using bit 7 of <feature> to define the new format
18:15:57  <Yexo> unless you want to assume all existing newgrfs don't have any trailing data
18:27:30  <frosch123> we could make it a complete new action, but that is also bad :)
18:28:06  <frosch123> or we could assume no grf has exaclty FF sets
18:28:57  <Yexo> I had thought of that, but as you say that is a worse solution
18:29:15  <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: execution expired
18:29:19  <frosch123> but the FF assumption might be wrong for weird station sets
18:29:31  <frosch123> some of them use a hell lot of sets
18:34:30  <Ammler> planetmaker: so we need something similar to gimp.png?
18:34:43  <Ammler> to clean those nfos
18:34:55  <planetmaker> hu?
18:35:03  <planetmaker> it doesn't do that either
18:35:11  <Ammler> it?
18:35:21  <planetmaker> or what do you mean?
18:35:36  <Ammler> well, I want to use nml2nfo :-)
18:35:44  <Ammler> but as you see, it didn't work
18:36:01  <Ammler> but on my local tests it does
18:36:15  <Ammler> that is very silly
18:42:44  <Ammler> planetmaker: how do I cleanup those nfos
18:42:53  <Ammler> that is IMO a requirement
18:43:12  <Ammler> a reason, I suggested .gimp.png
18:44:01  <Ammler> [NML2NFO] sprites/nfo/base/base-3017-rail-vehicles-arctic.pnfo
18:44:03  <Ammler> /usr/lib/python2.6/site-packages/ply/yacc.py:74: DeprecationWarning: the md5 module is deprecated; use hashlib instead
18:44:04  <Ammler>   import re, types, sys, cStringIO, md5, os.path
18:44:06  <Ammler> nmlc: Default language file "lang/english.lng" doesn't exist
18:44:13  <Ammler> that is why nmlc doesn't work
18:44:43  <Ammler> good we have a nml release test project now :-)
18:45:16  <Ammler> now we need opengfx to fail on that purpose, which need us to cleanup those nfos so we can "force" it to use nml
18:51:19  <planetmaker> well... the *.gimp.png files are NOT part of the repo. That's why it works
18:51:41  <Ammler> nah
18:51:51  <Ammler> those could
18:51:56  <Ammler> that's not the point
18:53:57  <Ammler> why not simply call those pnfo .nml.pnfo?
18:57:19  <Ammler> [20:44] <Ammler> nmlc: Default language file "lang/english.lng" doesn't exist <-- planetmaker, anyway, can we workaround?
18:58:07  <Yexo> mkdir lang; touch lang/english.lng
18:58:07  <Ammler> hmm, why does that error on installed nmlc, but not with the other nml?
18:58:26  <Yexo> different versions?
18:58:28  <planetmaker> I didn't call them differently as I didn't want to change the included file list for the 'main' pnfo files
19:00:43  <Ammler> well, but that is just your personal feeling, no real technical reason, right? :-)
19:01:17  <Ammler> Yexo: I updated my local nml to 0.1.0 too
19:09:18  <Ammler> this is very strange
19:10:41  <Ammler> the touch english.lng works, but can you explain the difference :-)
19:13:43  <planetmaker> a file being there or not
19:13:55  <planetmaker> nmlc obviously checks for its presence even when not needed
19:15:08  <Ammler> planetmaker: it is only needed for the installed nmlc
19:15:15  <Ammler> that is the confusing part
19:15:24  <planetmaker> ah. Ok, but still, should be done then
19:15:30  <Ammler> what?
19:15:39  <planetmaker> could be added to the nml2nfo part
19:15:48  <planetmaker> mkdir lang && touch lang/english.lng
19:15:56  <planetmaker> and clean: rm -rf lang
19:16:03  <Ammler> ah well
19:16:18  <Ammler> that is minor
19:16:32  <Ammler> the big issue is to cleanup the pnfo before :-P
19:17:08  <planetmaker> That I won't force.
19:17:22  <planetmaker> Either we make the decision to skip the pnfo files and remove them. Or not
19:17:27  <planetmaker> But no deleting them
19:17:42  <planetmaker> *deleting them on the fly before building
19:18:18  <Ammler> something like http://paste.openttdcoop.org/show/285/
19:19:49  <Ammler> that would be done with USE_NML2NFO only then
19:20:50  <planetmaker> that's not a good choice at all
19:21:23  <Ammler> but again, why not call those files nml.pnfo?
19:21:30  <planetmaker> it means that every newgrf will always be re-built. And any sense in dep check / only building what is required is not done anymore
19:22:04  <planetmaker> make makes sure that only those files are re-generated which are older than their deps
19:22:08  <Ammler> then we could cleanup and those quite easy
19:22:27  <planetmaker> and the rm basically makes sure that it always needs building. Which is contrary to the use case of make
19:22:42  <planetmaker> Ammler: I don't want to clean them automatically if they're up to date
19:22:59  <Ammler> yep, that is why I would call those nml.pnfo
19:23:07  <Ammler> you didn't answer that question, yet :-)
19:23:46  <planetmaker> the name of the files should not matter IMHO
19:24:05  <planetmaker> if you feel like, rename them
19:24:45  <Ammler> hmm, then I wonder, why we use pnfo, tnfo etc. and not just nfo
19:31:04  <planetmaker> Ammler: we use(d) the same file extension on grounds that it is the same file and that the grfs can be built with the pnfo alone. As the nml was not (yet) officially a requirement
19:35:32  <planetmaker> I don't mind though, to change the generated pnfo files to nml.pnfo
19:35:38  <planetmaker> might make it clearer
19:38:35  <Ammler> well, files which are built need to able to be cleaned
19:39:32  <planetmaker> Ammler: yes. But only files not part of the repo need cleaning
19:39:50  <Ammler> check maintainer-clean on openttd
19:40:12  <planetmaker> that's an option. To use/introduce a maintainer-clean.
19:40:16  <Ammler> well, that target is ugly, but I mean as example :-)
19:40:17  <planetmaker> we have that, don't we?
19:40:28  <planetmaker> it's not really ugly... it's a good idea
19:40:32  <Ammler> maintainer-clean on openttd is not useable
19:40:38  <planetmaker> why not?
19:40:44  <Ammler> it cleans the configure
19:40:56  <Ammler> it runs mrproper too
19:41:01  <planetmaker> so?
19:41:10  <planetmaker> it resets everything to a pristine state
19:41:23  <Ammler> so I can't use it for the package, as I would need to run ./configure just for cleaning
19:41:29  <Ammler> then again for building, which is stupid
19:41:58  <Ammler> acording to makefile spec, it should not clean such files
19:42:35  <Ammler> same issue as make install does also build
19:48:39  <Ammler> sometimes, you guys abuse depends ;-)
19:50:34  <planetmaker> Ammler: openttd's targets are quite standard
19:50:41  <planetmaker> http://www.gnu.org/software/make/manual/make.html#Standard-Targets
19:50:42  <Webster> Title: GNU `make' (at www.gnu.org)
19:51:00  <Ammler> planetmaker: yep, quite :-)
19:51:15  <planetmaker> it also says there: install builds things
19:51:24  <Ammler> common is "make && make install"
19:51:28  <Ammler> openttd just make install
19:51:29  <planetmaker> and distclean deletes configure. and maintainer-clean is more than distclean
19:51:47  <planetmaker> that's as it should be. According to the standard you quoted
19:51:49  <Ammler> yes, please read further
19:52:23  <planetmaker> ‘install’
19:52:24  <planetmaker>     Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use. If there is a simple test to verify that a program is properly installed, this target should run that test.
19:52:26  <planetmaker> what's more?
19:53:18  <Ammler> "The reason we say “almost everything” is that running the command ‘make maintainer-clean’ should not delete configure even if configure can b..."
19:53:31  <planetmaker> ‘distclean’
19:53:33  <planetmaker>     Delete all files in the current directory (or created by this makefile) that are created by configuring or building the program.
19:53:52  <planetmaker> ‘maintainer-clean’
19:53:54  <planetmaker>     Delete almost everything that can be reconstructed with this Makefile. This typically includes everything deleted by distclean, plus more:
19:54:03  <Ammler> :-)
19:54:05  <planetmaker> hm, but yes
19:54:18  <Ammler> I quoted from the same paragraph :-P
19:54:41  <planetmaker> well, I guess it could be changed
19:54:50  <planetmaker> I never read that far, I guess :-P
19:55:15  <Ammler> planetmaker: it is obvious, like openttd is simply unlogical
20:06:14  <Brot6> FIRS Industry Replacement Set - Revision 2057:51acb7e7c906: Feature: snow sprites for Sheep Farm ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/51acb7e7c906
20:06:14  <Brot6> FIRS Industry Replacement Set - Feature #1801 (Closed): Sheep Farm needs snow graphics (andythenorth) @ http://dev.openttdcoop.org/issues/1801#change-6885
20:06:27  * andythenorth wonders what the sheep eat :o
20:07:27  <Brot6> FIRS Industry Replacement Set - Feature #2744 (New): Esperanto translation (andythenorth) @ http://dev.openttdcoop.org/issues/2744
20:09:32  <planetmaker> sahra sand?
20:13:36  <Brot6> FIRS Industry Replacement Set - Revision 2058:d79bde49745f: Cleanup: remove unneeded pcx files (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d79bde49745f
20:13:56  <andythenorth> only 942 commits until r3k
20:14:02  <andythenorth> :O :)
20:15:29  <planetmaker> :-P
20:17:12  <Terkhen> oh, true
20:17:17  <Terkhen> we should test nml FIRS, right?
20:17:23  <andythenorth> yarp
20:27:19  <Yexo> no, it's broken
20:27:23  <Yexo> didn't have time yet to fix it
20:38:50  <Terkhen> oh, ok
20:39:01  <Terkhen> we could have a test game this weekend :P
20:39:22  <Terkhen> s/weekend/the weekend after it is done/
20:42:41  <Yexo> that should be this weekend :p
20:44:46  <Terkhen> :)
20:49:04  *** welshdragon has left #openttdcoop.devzone
20:50:34  *** welshdragon has joined #openttdcoop.devzone
21:03:53  *** andythenorth has left #openttdcoop.devzone
21:23:30  <Brot6> FIRS Industry Replacement Set - Revision 2059:89291af06613: Feature: snow graphics for Builders Y... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/89291af06613
21:35:08  *** frosch123 has quit IRC
21:54:55  *** ODM has quit IRC
23:29:27  *** Lakie has quit IRC

Powered by YARRSTE version: svn-trunk