=== Introduce branch develop ===
<hoijui> Tobi has prepared the buildbot
thanks<hoijui> so we could switch now
<hoijui> lets do it right now, during the meeting?
<hoijui> it is just a matter of us devs switching locally
<jk> yeah, already asked myself today, if I should commit to dev or master
<hoijui> yeah.. seems generally eveyrone used master still, as we said to give a clear change notice first
<jk> k
<zerver> so, anyone against switching now?
<jk> k so do a commit with notice to use dev branch from now on + description how to switch?
<kloot> switch after release, so we have an incentive
<hoijui> no, we should switch before the release
<hoijui> for once, because after the release really nobody should commti to master anymore
<hoijui> and second, to be able to test and setup stuff in advance
<kloot> it was a joke
<hoijui> and .. because there is no downside
<hoijui> k :D
<jk> >_<
<hoijui> was your commit thing also a joke, jK?
<zerver> The release must not be delayed by the switch
<hoijui> i dont think anything has to be changed in the repo for the switch
<hoijui> i just put develop HEAD to master HEAD
<hoijui> so they are at the same commit now
<hoijui> so if you do not have a local branch develop yet
<hoijui> you should be able to do:
<hoijui> git fetch
<hoijui> git checkout -b develop origin/develop
<jk> no, it wasn't
<hoijui> (if you are at origin master head
<hoijui> ok
<jk> esp. it was meant for abma & may be other regular 2nd level devs
<hoijui> we can make a comment for them
<jk> a commit is more obvious
<hoijui> if they dont use rss yes, but it makes little sense..
<hoijui> this is not soemthign in the history
<hoijui> but a decission taken at a point in time, independent of the repo content history
<hoijui> or a single brnach
<jk> and still many ppl fork us and may wonder why no commits were done anymore
<hoijui> and as we do it before the release, it is not too bad if someone fails to follow the rule
<hoijui> until the release
<hoijui> anyway, you cant do an empty commit
<jk> do a whitespace commit
<hoijui> if someone does not read RSS or comments but does read commti messages...
<hoijui>
<hoijui> thing is, that master will get updated to develop anyway
<jk> many ppl don't read forum
<hoijui> i mean a github comment
<jk> git hub comment are meant for commits & not general commit policy
<hoijui> who would read commit messages but not github comment, and would be stuck because of that?
<hoijui> it woudl only matter at release
<hoijui> where it will be announced anyway
<hoijui> Tobi, are you here?
<tobi> ya
<hoijui> please say something
<hoijui> regarding this matter
<hoijui> there simply is no mater.. nobody that follwos master closely will miss this
<hoijui> after two weeks or so (if the release has not happend by then) they would come ask
<zerver> I don't think it is an issue
<hoijui> if they missed all other clues
<hoijui> btw.. they get informed of the new branch, and see all commits there anyway
<tobi> yeah
<hoijui> whenever they fetch
<tobi> yup
<tobi> and the rss/frontpage of github shows that ppl push to spring/develop instead of spring/master, etc.
<jk> "whenever they fetch"?
<hoijui> btw, thw two comments i gave also work if you have local changes still, as you checkout an other branch, but to the same commit, which means git only changes the current branch reference
<jk> git pull doesn't inform me
<hoijui> the*
<hoijui> OMG
<hoijui> there is simply no issue
<hoijui> doh
<hoijui> i just realised..
<hoijui> omg == oh my god?
<hoijui> damn
<tobi> lol yeah
<hoijui> :D
<hoijui> i though of it as somethign different :D
<hoijui> just a sound
<hoijui> like duh
<zerver> there are variants such as OMFG
<zerver> and OMFGBBQ
<hoijui> :D
<hoijui> all start to look different now :D
<kloot> welcome to the internet?
<zerver> omfghax!!!
<hoijui> halleluya!
<jk> run "emerge wtf"
<jk> and then: "wtf omg"
<kloot> much like http://www.bash.org/?6460
<hoijui> :D
<tobi> so conclusion: no dummy commit, but just normal means of communications (forum)?
<hoijui> +1
<jk> hmm wtf doesn't know OMFG o_O
<zerver> speaking of hacks, I lolled reading gui_red_buildordermenu.lua the other day
<zerver> because it contains the word "hax" no less than 14 times
<tobi> high number of WTF/min
<jk> yeah, it sucks and it is the cause of many problems with BA
<zerver> yeah, reason I investigated it is that the UI was missing clicks
<hoijui> i guess they wil also use chilli some day for BA, and so it makes little sense to fix it?
<zerver> yea
<jk> first comes UHM fixes (to get release as soon as possible) then new addonhandler (needed for easy chili integration)
<hoijui> mmm
<hoijui> so.. can we switch to develop now?
<hoijui> i'll tell BD in chat and write PM to abma and koshi
<zerver> yeah
<tobi> possible open points (not blocking):
<tobi> - should develop be the "unnamed" branch in buildbot output?
<tobi> - I need to figure out how to change force builds through web to develop by default too, I found out later that they still do master
<hoijui> where would that name be, if it was not the unnamed one?
<tobi> I mean e.g. in installer filename
<tobi> develop is now like this: http://springrts.com/dl/buildbot/defaul ... -gdfc87f6/
<tobi> while master is like this: http://springrts.com/dl/buildbot/defaul ... -ge10dbf7/
<tobi> changing this is somewhat tougher because then stuff like the stacktrace translator needs to magically know whether an unnamed branch means develop or master (depending on build date?)
<hoijui> i woudl say master should stay unnamed
<tobi> +1
<hoijui> releases should not have "master" in the file names, s owe would have to manualyl rename them, and it can't hurt to have "develop" in non-release builds
<tobi> there are special cases anyway when building a tag, IIRC
<hoijui> mm
<hoijui> ah yeah.. casue releases are tags yo umean, ok
<tobi> so what was the idea with version no. in develop?
<tobi> cause if we switch silently all develop versions will eternally be called 0.82.3.something
<hoijui> http://springrts.com/phpbb/viewtopic.ph ... 24#p493324
<tobi> ah ty
<hoijui> hmm... yeah .. with this shceme, develop will have an irregular tag until the first minor release
<hoijui> as in.. it will have tag 0.83
<hoijui> and later on it will always have a + or -
<tobi> we can make a 0.83.0- tag in develop ofc
<hoijui> yeah
<hoijui> guess that makes sense, on the first commit after the release
<tobi> I wonder if I should still fix things that parse those version nums
<tobi> in any case I'll keep an eye open for breaking stuff
<hoijui> i always though of this beeing my duty so far..
<hoijui> ok, good
<hoijui> but i gues you though about other stuff then i did..
<tobi> did you fix something already then?
<hoijui> i was thinking mostly engine stuff.. all thigns inside the repo
<hoijui> not really, now
<hoijui> no*
<hoijui> i changed some comments
<hoijui> in unitsync
<tobi> buildbot stuff is all in repo too
<hoijui> and i prepared cmake stuff to parse versions and read git describe and so on
<hoijui> mm ok
<hoijui> yeah i did not think about buildbot
<hoijui> i was alwyas lazy to test this stuff so far
<hoijui> and i was a bit unclear abotu some stuff
<hoijui> still am ...
<tobi> its hard to test because many of it is system integration stuff
<hoijui> mmm yeah
<tobi> and we don't really have a test buildbot and test github
<hoijui> and for my stuff (cmake and git related, with export to a C/C++ file, plain text and possibly others), it matters .. for example when to let cmake reconfigure automatically, or at all, and how
<hoijui> best is to just ignore that, which is what we also do now
<tobi> so for buildbot, should I still use the update_version.sh script?
<hoijui> i mean: when building locally, and having local changes since the lat commit, we do create all version info/strings as if it was exactly this commit
<hoijui> let me see..
<tobi> I see its building lots of develop stuff already.. good :)
<hoijui>
<hoijui> where is that script?
<tobi> buildbot/slave/update_version.sh
<hoijui> ahh ok
<hoijui> that will be done by cmake in the future
<tobi> ah, will, so isn't yet?
<hoijui> ah an other thing... if we do the whole version stuff through cmake, by reading from git-describe or a VERSION file (in case of a tarball), how would that be handled in VS or other systems?
<hoijui> yep, isnt yet done
<hoijui> so using this script is ok..
<hoijui> we can just empty it if it is not requried anymore
<hoijui> and remove the call to it form buildbot in a few years or so
<jk> imo even VS should use cmake
<tobi> just ignore those other systems for now
<hoijui> yeah that would be the optimum of course
<hoijui> ok
<tobi> VS using cmake would be cool but quite a lot of work AFAIK
<jk> cmake can generate VS projects
<tobi> yes, but all logic to find libs / set flags must have VS specific variant
<hoijui> can you give an example?
<tobi> me?
<jk> setting flags for VS doesn't make sense cause it won't sync
<hoijui> yeah.. i mean
<tobi> they don't want to debug?
<hoijui> cmake commands already abstract some stuff
<tobi> you need flags for much more than fixing sync
<hoijui> ah fllags.. yeah true
<hoijui> but for finding libs.. i would have though it should abstract that out
<jk> hmm those are gimmicks
<jk> (flags for other things than syncing)
<tobi> and in any case all gcc flags that we enable by default should be made conditional
<hoijui> zerver, you tried generating VS projects with cmake?
<hoijui> you mean, configurable through cmake?
<tobi> I think for libs it needs to look in ${project-root}/vclibs
<hoijui> i guess that cant hurt
<tobi> instead of /usr/lib etc.
<hoijui> yeah, but that is a simple change in a single place, from "mingwlibs/" to "vclibs/"
<tobi> kk
<hoijui> at least i think
<jk> that dir is already configurable via a cmake tag, or not?
<hoijui> yeah
<hoijui> so... everybody switched to develop already?
<tobi> me yes
<jk> hope so
<zerver> I did not try generating VS projects
<hoijui> me too
<kloot> any way to make github display the dev branch by default?
<tobi> ah, yes
<hoijui> ther is, but Tobi pointer out last time....
<hoijui> somethign, i forgot :D
<hoijui> ahh yeah
<hoijui> it woudl probably also mean that people will get rbanch develop as default
<hoijui> and one of the idea we had was, to use master as the default
<tobi> not so sure that becomes the default for git
<tobi> changed now, in any case
<hoijui> for cases where linux users have to compile spring release versions themselfs
<hoijui> ok
<kloot> nice
<tobi> if you go to https://github.com/spring/spring you see develop branch now
<hoijui> ahh yeah
<hoijui> i do a test clone to see the default branch....
<tobi> k
<zerver> nice
<hoijui> default clone brnach is develop now
<tobi> ah ok, didn't expect that
<hoijui> i don't care too much
<hoijui> default checkout branch and what is shown by default on github is both not too important to me
<hoijui> would be nice if it coudl be different, but maybe also confusing
<hoijui> was not too much work so far to tell users to cheocut a tag after cloning
<hoijui> checkout*
<jk> hmm wiki tutorial needs update
<jk> will see tomorrow
<hoijui> forum PM sent to abma and koshi
<hoijui> next? :D
<tobi> brb
==> The develop branch is now up and running
=== How to test for 'must not compile' in UnitTests? ===
<jk> I need to test if code is illegal as wanted
<kloot> lol
<kloot> the only way to test if something does not compile... is by compiling it
<hoijui> hmm... i coudl imagine that would have to be done in somethign else
<hoijui> or say.. it would probably not be called unit test anymore
<jk> today I encoutered the new AI script with run.sh
<jk> can't I do something similar?
<hoijui> hmm.. or still call it that, but do it with cmake "trickery", not using boost
<hoijui> ah yeah
<jk> instead of running spring, it runs g++
<hoijui> that is also possible, though that can only be run on the buildbot
<hoijui> or say.. it is linux specific
<hoijui> ahh..
<hoijui> best woudl be, if it coudl be done wiht CTest i guess
<hoijui> that is what we use in CMake ...
<hoijui> i thnk :D
<tobi> should be possible to hack it into CMake isn't it?
<hoijui> yeah, pretty sure
<hoijui> would be a plus if CTest has something to support that already
<hoijui> http://www.cmake.org/cmake/help/ctest2.6docs.html
<jk> ah so Boost UnitTests get run by CMake's CTest currently?
<hoijui> it is what we use
<hoijui> yes
<hoijui> The "ctest" executable is the CMake test driver program. CMake-generated build trees created for projects that use the ENABLE_TESTING and ADD_TEST commands have testing support. This program w
<tobi> cmake should be capable of this also as part of its ./configure `emulation' I think, just an idea in case CTest doesn't support this
<hoijui> ADD_TEST(NAME testCheckIsAbcCompiling COMMAND "${CMAKE_CXX_COMPILER}" "MyTestSource.cpp")
<hoijui> maybe somethign like that...
<hoijui> is hte best idea i could come up with
<jk> COMMAND?
<jk> ah nvm
<jk> it is a op
<hoijui> path to the source will most likely have to be absolute
<tobi> + need to inverse the result
<hoijui> or you had to install the source or something... that is probably the ugly part
<hoijui> ahh yeah :D forgot that
<tobi> maybe if (you can make it to) run it as shell command you can simply run `! g++ -c myfailingfile.cpp'
<hoijui> guess it would have to be a wrapper script
<hoijui> i am not sure how ctest even works
<tobi> or that, wrapper script failgcc :)
<hoijui> if it looks at the commands return value, on stderr or if it intereact with boost testing in some special way (i think not)
<hoijui> mm
<jk> https://svn.boost.org/trac/boost/wiki/C ... ssionTests
<tobi> ah there you have it
<hoijui> hmm.. sounds good
<hoijui> but i guess one had to include the boost macros
<hoijui> or copy and adapt them
<hoijui> i guess they dont come wiht cmake, but are somewehre in the boost repo
<hoijui> to be able to use commadns like boost_test_compile_fail
<jk> yeah, that what I am googling atm :)
<hoijui> ok
<kloot> http://svn.boost.org/svn/boost/branches ... ting.cmake
<hoijui> nice
<zerver> WILL_FAIL TRUE
<hoijui> :D
<hoijui> guess that is solved then..
<hoijui> tell me if you want me to do it, jk
<jk> thx, first trying it myself
<hoijui> ook
==> jK will try to implement the 'failing' unit tests
=== Use if (unit) {} instead of if (unit != NULL) {} ? ===
<zerver> Yeah, I'm not sure I understand it
<hoijui> i ma wiht Tobi there
<hoijui> aehh..
<hoijui> i mean.. the green person :D
<kloot> it was I
<hoijui> ok
<zerver> pointer = NULL is not confusing as I see it. pointer = 0 is a bit confusing though
<jk> I didn't said it confusing
<hoijui> it is about whetehre to use "if (unit) {}" or "if (unit != NULL) {}"
<jk> I said it is as: if (foo == true) {}
<zerver> Ah
<zerver> so you want (unit != NULL) always
<jk> no I want "if (unit) {}"
<hoijui> Kloot and me want that, jk wants the other thing
<zerver>
<hoijui> i take it, you do not care? :D
<zerver> I think I vote for (unit != NULL) in that case, because it is 100% clear
<jk> clear as if (foo == true) {} ...
<zerver> Why?
<jk> it is a redundant check
<kloot> you do not instantly see what foo is
<jk> neither for boolvars
<jk> and still you don't check them
<hoijui> with Kloots system, if a var is used alone in a booelan expression, you DO know that it is boolean
<zerver> if everyone uses (unit != NULL) then those checks that lack it can be assumed to be boolvars
<kloot> with the != NULL you know that when the != check is missing it must be boolean
<hoijui> hehe :D
<zerver> you were quicker
<hoijui> awesome
<zerver> but this means everyone must also use (int != 0) etc
<hoijui> yeah
<jk> you can never rely on that
<zerver> and please no assignment of "0" to pointers
<hoijui> that is not a contra argument
<jk> it is
<kloot> (technically I would like != 0x0 more for pointers, since null in c++ is this strange non-typesafe leftover)
<jk> any rule that is not always true is wrong
<hoijui> hehe
<jk> better use c++11 & NullPtr
<hoijui> do not use superior standard ever, cause its full potential only kicks in if it is used always
<hoijui> <- nope
<hoijui> is c++11 a realistic option?
<hoijui> for now
<jk> it is
<jk> most important stuff should work in gcc4.4 already
<hoijui> ok
<jk> ah NullPtr is 4.6 only :/
<hoijui> what about VS? :D
<hoijui> mmm
<zerver> Never seen any nullptrs
<jk> VS is very far, too
<hoijui> ok
<zerver> error C2065: 'nullptr' : undeclared identifier
<zerver> but the IDE colors it like a keyword
<hoijui> i guess it would, at best, work with latest VS only
<jk> you need to define a compileflag to enable c++0x/c++11
<hoijui> well anyway.. gcc 4.6 is not quite standard yet
<hoijui> so about the initla thing... i guess we will not settle for jk's suggestion?
<jk> static_assert, extern templates, auto types, strongly-typed enums are 4.4 already
<hoijui> define Kloots way as standard? or do not care?
<zerver> Not a very big deal I think. We 'recommend' use of Kloots way?
<hoijui> i am fine wiht that
<kloot> depends, if you want coding standards to be strict or recommended
<kloot> or strongly recommended ^^
<hoijui> hehe :D
<zerver> :)
<zerver> Spank those who fail to conform
<hoijui> luckily, in spring it is often quite clear anyway
<hoijui> like wiht the example of "unit"
<hoijui> it is pretty clear that it is not a boolean, due to its name
<hoijui> if it was unclear, i would like the != NULL to be used always, but i don't feel strong about this in general
<hoijui> i woudl rather get to beed soon
<kloot> I reserve the right to issue a damn good thrashing every time you do type &val
<zerver> :)
<hoijui> :D
<zerver> int a, &b, &c;
<hoijui> i hate these statements anyway
<hoijui> should be 3 lines
<jk> +0.7
<kloot> you can't do that with references
<hoijui> ah yeah :D
<zerver> int a, &b=X, &c=Y;
<zerver> whatever
<zerver> but you get the point
<hoijui> yeah.. so you need that ugly syntax to do be able to use even more ugly syntax
<hoijui> awwww i will have nightmares abotu this!
<jk> still it is a bordercase, you should define var where they get used, and not at the top of the function (that's the usage of such code)
==> We recommend if (pointer != NULL) {}, if (int != 0) {}, if (bool) {} etc.
=== Release ===
<zerver> So, will we release soon?
<hoijui> yes yes
<jk> need to fix UHM first
<zerver> lovely
<jk> but I give my best to fix them fast
<kloot> why dont you mantis the issues also?
<hoijui> yeah, just assing them toyourself, then nobody else will work on it, and it can be seen in the roadmap
<hoijui> can even be very simple
<zerver> If there are many issues, then you also have a chance of getting some help
<jk> cause I work on the code and already heavilly reorganized the code
<hoijui> we dont have to fully grapsh the problem in detail
<hoijui> grasp
<zerver> okay, nm then
<kloot> would have been better if you had fixed/reported the minor stuff before reorganizing
<jk> I encountered them afterwards
==> Release will be done after unsynced heightmap bugfixes are completed
