Integrated Version ChrisIN-Final-1 [2008/03/12] *r11485*

[chrissicom]

Ok, after some thoughts about the future of ChrisIN, I decided that the current version will stay as it is. I.e. there might be bugfixes but I will not update it to newer revisions. Especially the splitup of so many header files (didn't really get yet why it was done, I see more disadvantages than advantages to it) it is nearly impossible to solve the mess caused with all the patches applied. So I will leave the current version in this thread and start coding a new ChrisIN (before you ask, savegames will most certainly not be compatible with the old ChrisIN that's why I leave it here) and open up a new thread then so it will be easy to differentiate between the two version . Thanks for all the support so far and I hope you understand that creating a new build of ChrisIN is the better solution!

[Sir A. Boey]

Great news and I'll be looking forward to the NEW ChrisIN version

[mrMann]

Great news and I'll be looking forward to the NEW ChrisIN version

+1

[Rubidium]

....Especially the splitup of so many header files (didn't really get yet why it was done, I see more disadvantages than advantages to it) it is nearly impossible to solve the mess caused with all the patches applied. ...

The whole idea about it is to speed up the compilation by not letting the compiler parse all kinds of unneeded stuff. As a result of that compilation became already about 10-30% faster for full compiles. For partial compiles that are needed due to changed headers the speed up can be much more, but that depends highly on the functions used (and thus the amount of headers that needs to be included). Finally it also causes quite a few functions to be in a more logical place.
So from a developer's point of view there are quite a few advantages that have a longer lasting 'impact' than the disadvantages of having to update your patch once.

[chrissicom]

I have read about the reason to seed up compilation in the logs, but at least in MSVC I don't really see any speed increases in compilation that's why I was wondering about that point. It might be faster in a benchmark way but I didn't "feel it".

[Vaulter]

vaulter@vaulter-desktop:~/bin/OpenTTD-Dev$ ./configure --enable-debug=1 --disable-strip
vaulter@vaulter-desktop:~/bin/OpenTTD-Dev$ make
vaulter@vaulter-desktop:~/bin/OpenTTD-Dev$ cd objs/debug
vaulter@vaulter-desktop:~/bin/OpenTTD-Dev/objs/debug$ ln -s ../../bin/data data
vaulter@vaulter-desktop:~/bin/OpenTTD-Dev/objs/debug$ ln -s ../../bin/lang lang
vaulter@vaulter-desktop:~/bin/OpenTTD-Dev/objs/debug$ ./openttd -d999
dbg: [misc] Scanning for tars
Segmentation fault (core dumped)
vaulter@vaulter-desktop:~/bin/OpenTTD-Dev/objs/debug$ uname -a && cat /etc/issue
Linux vaulter-desktop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
Ubuntu 7.10 \n \l

can somebody help me?