CodeBlocks problem

[Mattn]

btw. it would be nice if you would read the coding guidelines again

[Duke]

You're right to some extent. Even if we could prove it's a C::B bug, we couldn't do much about. I just wanted to help you find out whether it's 'just you'.

If you can easily apply the patch to current trunk, you can as easily create a fresh patch based on trunk

You may also want to find out whether there is a difference between compiler and linker errors being clicked on.

[criusmac]

I applied the diff files to the current trunk, and threw out my versions of:
ufo.workspace
game.cbp

then I compiled.

That's it, that's all. As soon as I placed my g_linkedlist.c file back into the game.cbp, the errors all went away, and everything worked fine.

This problem, I suspect, happens everytime a new game.cbp is created since I always throw out my version, and use the trunk, and so I likely always create the same link problem every time the game.cbp file is updated.

I have no idea why the diff file worked so easily for me, when it won't for you.

If you are still interested in pursuing this, attached is the patch based on the trunk as of, uh, about 5 minutes before I hit post on this message.

As stated before, this is a work in progress, and so it will not follow the coding guidelines. To make it easier to use, I also removed the game.cbp file from the diff.

[Mattn]

it would be really cool if you could at least use the updated version that i've appended to the tracker item.

[Mattn]

g_linkedlist.c is not included in the patch, isn't it?

i also don't see which codeparts from the patch at sf.net should need this. as it compiles clean with current trunk (except one compile error that was introduced for you to look at the position)

[Duke]

I also noticed that your game.cbp contains backslashes in the paths. C::B doesn't need that even on Window$. That might even be the source of your error.
What happens if you use the standard cbp from trunk ?

[criusmac]

game.cbp is the trunk version, gotten via svn, and then I used CodeBlocks to add g_linkedlist.c into the game sources.

So, if CodeBlocks wrote the file incorrectly, then, uh... Well, I don't modify game.cbp by hand, so I really don't know why it would be wrong.

I can try to use the code you appended to the tracker, sure. I was just continuing my coding from where I left off.

I removed g_linkedlist.c purposely from the diff file I uploaded into this conversation to introduce the compile/link errors and make it easy for you to get the exact errors I was seeing. I have *no* idea how you avoided the errors and got a clean compile when I very specifically made sure you would not get a clean build.

Since I updated my source code via svn just minutes before I created this diff file...

And the codeparts from the patch that need this file are displayed in the first message of this conversation:
The errors I get are:
.objs\game\src\game\g_actor.o||In function `G_ActorDamage':C:/cprogs/UFOAI-2.3-dev-medikits/src/game/g_actor.c:213: undefined reference to `LIST_AddPointer'|
.objs\game\src\game\g_actor.o||In function `G_ActorTreat':C:/cprogs/UFOAI-2.3-dev-medikits/src/game/g_actor.c:404: undefined reference to `LIST_GetByIdx'|
:C:\cprogs\UFOAI-2.3-dev-medikits\src\game\g_actor.c|419|undefined reference to `LIST_Remove|

So, it is g_actor.c that needs g_linkedlist.c.

I have no idea where to go from here. To get a clean compile, your CodeBlocks settings must somehow be different from mine, or something, and I've never been informed of any of the CodeBlocks settings for this project. I did not change any CodeBlocks settings from when I first installed CodeBlocks, so maybe they really are wrong.

Honestly, if you don't include g_linkedlist.c in the game project, but you are including my changed g_actor.c, there should be no way to get a clean compile.

[criusmac]

Upon closer reading of your statements, I have come to the conclusion that you may not realize I am trying to change the UFO: AI code to add the new form of Medikits.

From what I can gather, you are stating the UFO:AI original code project compiles fine without g_linkedlist.c - my newly added file. This probably means that you are not using my new g_actor.c changes, which requires g_linkedlist.c.

Please download the trunk, and then apply my diff file without modifying anything, and try to compile/link it. You will get errors - this was done on purpose. Double clicking on the last error (for me) causes CodeBlocks to open up an empty file with the same pathname of a proper existing file. With this strangely empty file, if you save all or build, you can overwrite the real file with the empty file, thus losing the real, full file completely.

If CodeBlocks Windows version is adding backslashes into the project file, and it can't use these blackslashes properly, which causes it to completely erase files, that sounds like a CodeBlocks bug, and a very serious one.

[Duke]

Ok, I
- svn updated to r27510
- applied your diff (5 posts above) without conflicts
- got the three LIST_* linker errors
- clicked the last one (it's singleClick btw) and C::B nicely opened g_actor and found the correct line

[criusmac]

Great! Thank you.

It's obviously something wrong with my CodeBlocks then. I'll update to the latest version (I was using svn build rev 5456 (2009-02-14 11:03:04) gcc 4.2.1 Windows/unicode), and see if the problem goes away. If not, well, hmm. I haven't a clue what else to do.

[criusmac]

I just downloaded svn build rev 5731 (2009-08-15 03:48:58) gcc 4.2.1 Windows/unicode from mattn's CodeBlocks.zip, and it worked perfectly. So, I guess I happened to find a bug in the previous version.

Thanks. It's solved.

[Duke]

It's always a good idea to hunt them bugs down to their very end...

[Muton]

sed.exe from gnu is not useable under mingw32

I've replaced the GNU sed.exe with a sed.exe from an older C::B build (attached)

GNU sed errors
sed.exe: -e expression #2, char 1: unknown command: `V'

MinGW build VS MSYS build

Some programs when used under the MSYS shell can be tricky. One such example is sed.

$ ls *.txt -1 | sed -e s/.exe/\&\!/g

Normally, sed will append "!" to the end of every .txt file, but if sed was compiled and link using MinGW, MSYS will treat it as a native application and will try to change "/" to "\" to compensate for the difference between UNIX path and WIN32, resulting in unpredictability when used under the MSYS shell.

[Mattn]

where to get that sed version? we need an updated version for the c::b script.

[Muton]

is part off msysCORE

no need for
codeblocks.sh
//   download_archive http://downloads.sourceforge.net/gnuwin32/ sed-4.2-bin.zip sed.zip