Hows our HEAD?

#1 @dreamer

what command are you using to get your files from cvs?

is this it :

cvs -z3 -d :pserver:ur-name@cvs.garagegames.com:/cvs/torque checkout -r HEAD torque

#2 Yes thats the one.

#3 Using a mandrake 9.2 download install [ 3 cd], which compiles the last 1.3 .bin from gg without any problems,


with cvs HEAD:
// g++ (GCC) 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)


--> Compiling console/BASgram.c
In file included from platform/platform.h:14,
from console/console.h:10,
from console/BASgram.y:8:
platform/types.h:38: error: syntax error before "F32"
platform/types.h:39: error: syntax error before "F32"
// **** ERRORS - continue on

#4 Ok, I've found a file I believe may be the mysterious config_types.h
Only it appears that this file is supposed to be config_types.h.in and is supposed to be modified by configure to suite your platform.
I'm currently working out how to get around this.

*update*
I ran configure on a download version of ogg from xiph and it spit out this file for config_types.h

#ifndef __CONFIG_TYPES_H__
#define __CONFIG_TYPES_H__

/* these are filled in by configure */
typedef int16_t ogg_int16_t;
typedef u_int16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef u_int32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;

#endif

#5 Ok after adding the missing file, I'm getting exactly the same errorrs on a clean head downloaded today both in gcc4 (SuSE) and gcc3.3(Gentoo)

So at least we are getting roughly the same errors now.

#6 Alright, on a hunch I cleared my EXPORTs and re-downloaded the head.
No missing config_types.h this time, but I am getting this error.

./console/consoleObject.h:201: error: ISO C++ forbids declaration of 'ConsoleObject' with no type
./console/consoleObject.h:201: error: 'ConsoleObject' declared as a 'virtual' field
./console/consoleObject.h:201: error: expected ';' before '*' token

This is all coming from line 201 obviously of consoleObject.h which reads.

virtual ConsoleObject*  create() const = 0;

This looks legitimate to me, I'm not seeing the error with this statement.
Any ideas?

#7 I found the problem. In this instance ConsoleObject needs a forward declaration.
On line 53 of consoleObject.h add

class ConsoleObject;

This will be just under 2 other forward class declarations.

Ok now on to the rest of this stuff.

Noticed alot of annoying messages about mcpu being deprecated. So in mk/conf.UNIX.mk look for the line containing mcpu=i686 and replace it with march=i686

At this point my errors again exactly match Charles errors, I'm not sure why but this line seems to throw a syntax error.

static const F32 Float_One  = F32(1.0);

I'm currently looking into it. But this is the first compilation error now. All the lines written similarly throw the same error.

*update*
Replace that line with this one

static const F32 Float_One  = 1.0;

Similarly remove the type from the assignment in all other statements in that general area. There's about 10 of them.

Ok now we have

./platform/types.h:93: error: syntax error before 'isPow2

Line 93 in types.h is

inline bool isPow2(const U32 in_num)

Which is the function block for isPow2

I'm having extreme difficulty finding the error, so for now I'm commenting it out, I'll come back to it when I see something complain about it missing.

For now, the next error shows up on line 106
On line 106 the error is resolved if you remove the U16 from the line.

Next error is ./platform/types.h:116: error: conflicting types for 'endianSwap
Line 116 is

return U32(((in_swap >> 24) & 0x000000ff) |

I've done a grep of the entire code base and this function does not appear to used anywhere to so I have commented it out.

Noticing the same error for getMin and getMax I have removed all instances of it except the ones for double.
This throws alot of warnings but near as I can tell it's safe.

#8 Our next series of errors begins in PlatformAssert.h
Specifically

./platform/platformAssert.h:13: error: syntax error before 'PlatformAssert'

That line reads

class PlatformAssert

The error therefore must be up higher.
The only lines above 13 are these

#ifndef _PLATFORMASSERT_H_
#define _PLATFORMASSERT_H_

#ifndef _PLATFORM_H_
#include "platform/platform.h"
#endif

#9 I still can't figure this one out, am I completely alone in this error?

#10 What file is including platformassert.h?

#11

--> Compiling console/BASgram.c
In file included from ./platform/platform.h:18,
                 from ./console/console.h:10,
                 from console/BASgram.y:8:
./platform/platformAssert.h:13: error: syntax error before 'PlatformAssert'

#12 I tried templates for getmin and max and I don't know how to really get it to work...

#13 I think the next problem is ... platform/platform.h

convertHostToLEndian
convertLEndianToHost

#14 The F32 problem appears to be an issue of compiling a "C++" file as a C file. Not being a C++ affectionado (I love OO, just not C++'s flavor of it), I'm not sure, but it appears to me that using "F32 (something)" does something similar to a type cast or some other form of data format conversion. However, this doesn't make any sense when you compile that file as a C file.

In engine/targets.torgue.mk, in the SOURCE.CONSOLE variable assignment, the engine/console/BASgram.cc file is referenced. However, it doesn't exist. When its built from the engine/console/BASgram.y file via bison, the set of make rules end up making engine/console/BASgram.c.

This .c file is then compiled as a "C" file and the F32 problem shows up.

On my box, renaming engine/console/BASgram.c to engine/console/BASgram.cc eliminates the F32 problem, but I was getting other problems, I think related to the lex file(s).

I noticed that engine/console/basgram.cc exists, so in engine/targets.torque.mk, I changed the reference from engine/console/BASgram.cc to engine/console/basgram.cc and that gets me past that part of the build process.

I suspect that if all of the lex and yacc files were processed on my box, I wouldn't have a problem compiling the BASgram.cc file I generated on my computer.

The easiest non-complete-hack fix in CVS for this problem I can think of is to simply rename the engine/console/basgram.cc file to engine/console/BASgram.cc to match the case of engine/console/BASgram.y. A real hack of a fix would be to make the change in the engine/targets.torque.mk file like I did.

The best fix would be to fix the yacc and/or lex rules being used to generate these file, but I didn't look further into this because engine/platformX86UNIX/x86UNIXFont.cc stops on the missing engine/platformX86UNIX/x86UNIXFont.h header file.

#15 Ok folks we need to back track here, I am going to grab a frsh CVS this morning and replace alot of things that really should be templates, I'll let you know what I find.

*update*
I think these were here before, but I can't be sure anyways after apply the fix to make, and the forward declaration of the consoleObject class, I get this warning, that really has me worried.

./platform/event.h:128: warning: invalid access to non-static data member 'PacketReceiveEvent::data' of NULL object
./platform/event.h:128: warning: (perhaps the 'offsetof' macro was used incorrectly)
./platform/event.h:130: warning: invalid access to non-static data member 'ConnectedReceiveEvent::data' of NULL object
./platform/event.h:130: warning: (perhaps the 'offsetof' macro was used incorrectly)
./platform/event.h:132: warning: invalid access to non-static data member 'ConsoleEvent::data' of NULL object
./platform/event.h:132: warning: (perhaps the 'offsetof' macro was used incorrectly)

It reffers to these lines of code

/// Header sizes for events defined later on.
/// Byte offset to payload of a PacketReceiveEvent
const U32 PacketReceiveEventHeaderSize = Offset(data,PacketReceiveEvent);
/// Byte offset to payload of a ConnectedReceiveEvent
const U32 ConnectedReceiveEventHeaderSize = Offset(data,ConnectedReceiveEvent);
/// Byte offset to payload of a ConsoleEvent
const U32 ConsoleEventHeaderSize = Offset(data,ConsoleEvent);

*update* Since he above were just warnings, abeit dire warnings, I am skipping those until I can understand more about what the compiler is complaining about. I have noticed something else for which there is a work-around but as far as I know there is no cure for at the moment.
Contained in the code is a basgram.cc file, when you compile this is evidently supposed to be replaced with a BASgram.c file.
Near as I can tell the BASgram.c file is meant to replace basgram.cc as it seems that basgram.cc is really mostly a collection of yacc macros.
So what we wind up with is the compiler seeing a BASgram.cc file as well as the basgram.cc file.
Since Linux's file system is case sensitive and windows is not, my guess would be that on a windows computer this would make no difference but on ours, again these are two seperate files and the compiler treats them as such.

For the short term I have successfully managed to rename BASgram.c to BASgram.cc and the old basgram.cc to basgram.bak

Now we have a couple of new errors I am working on.

--> Compiling console/BASgram.cc
console/BASgram.y:28:1: warning: "alloca" redefined
In file included from /usr/include/stdlib.h:606,
                 from console/BASgram.y:6:
/usr/include/alloca.h:36:1: warning: this is the location of the previous definition
y.tab.c: In function 'int yyparse()':
y.tab.c:1582: error: 'yylex' was not declared in this scope
y.tab.c:2388: error: 'yyerror' was not declared in this scope
y.tab.c:2503: error: 'yyerror' was not declared in this scope

#16 See my previous post.

I'm thinking that the BASgram.cc compile errors you're getting are caused by mixing up the results of different versions of yacc and lex, or bison and flex to be more precise.

If you aren't going to use the basgram.cc file that is in CVS, you should process all of the yacc and lex files with compatible versions of yacc/bison and lex/flex. You still make run into a few problems with that though. Its been years since I hacked around with yacc and lex, but I recall having to tweak things a bit.

To me, being able to rebuild the yacc and flex output when that is already being checked into CVS is not a huge concern. If basgram.cc would just get renamed in CVS to BASgram.cc like it should be to correlate with the .y file, this problem should be resolved.

#17 Hey, has any one been able to solve the basgram errors? I used to build the TGE 1.5 on debian but now on another debian Im facing these errors. I just need to try to figure the difference with the build environment unless some one already knows solution?

#18 These posts are pretty old; can you try downloading stock 1.4.2 [assuming you don't have a 1.5 license, or download 1.5 if you do] and seeing if it still manifests?

Gary (-;

#19 I don't understand I should have exactatly the same files that are in 1.5 but still it doesnt compile. I was able to build the fresh copy of 1.5 on the same machine under same conditions though.

#20

Quote:I don't understand I should have exactatly the same files that are in 1.5 but still it doesnt compile. I was able to build the fresh copy of 1.5 on the same machine under same conditions though.

Then you don't have exactly the same files that are in 1.5 :-)

Gary (-;