[RandomTiger]

Yes, though I wont be able to help you.
I havent used that in ages.

[Bobboau]

FS_open is directly compileable with GCC (I beleve), and that is free (I beleve)

[Sesquipedalian]

Things as they stand now:

1) All code is downloaded and sitting on my hard drive with the directory structure preserved.

2) DJGPP (which does GCC compilation) is installed and ready to go (if I knew what I was doing).

Now, do I have to manually go through each and every folder and first compile its contents into .o files, and then somehow link them together into an exe, or is there an easier, less time consuming way to compile them all?

[Inquisitor]

There should be a makefile in the CVS download.

You need to use that, but I think it might be broken.

[Sesquipedalian]

You know, making a new sexp was easy, but this damn compliing stuff is impossible!

If I abandon this program and go to straight up GCC, where can I get an actual GCC binary, and is it any more straightforward?  All I could find were source code versions, which don't do me a whole lot of good since I want something to compile source code with...

Basically, I'm just trying to get familiar with the damn thing, so using the Dos based interface thingy they gave to go with the actual program I try using the "Make" command to do something with fs2_open.w32.mak.  Nothing happens.  No output, nothing.  I try "Compile."  Still nothing.  

[RandomTiger]

If you could just acquire visual C++ then its all really simple.
Otherwise you'll just have to read the docs with the free compiler and work it out.

If this is a total one off then perhaps one of the coders will do it for you but if you expect to make a regular thing of it I think you'll find we have our own code to implement.

Search the web there will be tutorials and stuff for that compiler Im sure.

[Sesquipedalian]

In case anyone is interested, the changes made are the following:

In sexp.h:

Code: [Select]

//sexpressions with side effects
.
.
.
#define OP_SHIELDS_ON (0x0058 | OP_CATAGORY_CHANGE | OP_NONCAMPAIGN_FLAG) //-Sesquipedalian
#define OP_SHIELDS_OFF (0x0059 | OP_CATAGORY_CHANGE | OP_NONCAMPAIGN_FLAG) //-Sesquipedalian


In sexp.cpp:

Code: [Select]

sexp_oper Operators[] = {
//   Operator, Identity, Min / Max arguments
.
.
.
{ "shields-on", OP_SHIELDS_ON, 1, INT_MAX}, //-Sesquipedalian
{ "shields-off", OP_SHIELDS_OFF, 1, INT_MAX}, //-Sesquipedalian

Code: [Select]

void sexp_shields_off(int n, int shields_off ) //-Sesquipedalian
{
char *ship_name;
object *objp;
int num;

for ( ; n != -1; n = CDR(n) ) {
ship_name = CTEXT(n);

// check to see if ship destroyed or departed.  In either case, do nothing.
if ( mission_log_get_time(LOG_SHIP_DEPART, ship_name, NULL, NULL) || mission_log_get_time(LOG_SHIP_DESTROYED, ship_name, NULL, NULL) )
continue;

// get the ship num.  If we get a -1 for the number here, ship has yet to arrive.  Store this ship
// in a list until created
num = ship_name_lookup(ship_name);
if ( num != -1 ) {
objp = &Objects[Ships[num].objnum];
if ( shields_off )
objp->flags |= OF_NO_SHIELDS;
else
objp->flags &= ~OF_NO_SHIELDS;
} else {
p_object *parse_obj;

parse_obj = mission_parse_get_arrival_ship( ship_name );
if ( parse_obj ) {
if ( shields_off )
parse_obj->flags |= P_OF_NO_SHIELDS;
else
parse_obj->flags &= ~P_OF_NO_SHIELDS;
break;
#ifndef NDEBUG
} else {
Int3(); // get allender -- could be a potential problem here
#endif
}
}
}
}

Code: [Select]

// high-level sexpression evaluator
int eval_sexp(int cur_node)
{
[blah blah blah...]

op_num = find_operator(CTEXT(cur_node));
switch ( op_num ) {
.
.
.
//-Sesquipedalian
case OP_SHIELDS_ON:
case OP_SHIELDS_OFF:
sexp_shields_off( node, (op_num==OP_SHIELDS_OFF?1:0) );
sexp_val = 1;
break;



In sexp_tree.cpp:

Code: [Select]

struct sexp_help_struct {
int id;
char *help;

} Sexp_help[] = {
.
.
.
{ OP_SHIELDS_ON, "shields-on\r\n"
"\tCauses the ship listed in this sexpression to have their shields activated.\r\n\r\n"
"Takes 1 or more arguments:\r\n"
"\t1+:\tName of ships to activate shields on." },

{ OP_SHIELDS_OFF, "shields-off\r\n"
"\tCauses the ships listed in this sexpression to have their shields deactivated.  \r\n\r\n"
"Takes 1 or more arguments:\r\n"
"\t1+:\tName of ships to make deactivate shields on." },



Basically, these sexps are based entirely off of the code for ship-invulnerable and ship-vulnerable, except the flags being referenced have been changed.

[RandomTiger]

Hmmm. I just tryed compiling the makefiles in debug and release and they did compile but both crashed.

I also tryed downloading djgpp and using that but I couldnt even get it starting to compile using the makefile.

Doh.

[Inquisitor]

Like I said: I think the makefile is busted

penguin's been lord of that, and, well, he's been otherwise occupied. Anyone want to take a crack at it, lemme know.

[EdrickV]

GCC support is currently broken, as I've mentioned before. The included Makefile is Linux specific and I don't know enough about them to make a Cygwin/Win32 version. (And the old one I have that used to work, with my older copy of the source code, was from before the case of all the file/folder names was changed so needs major editing and may still not work quite right 'cause there may be new stuff it's missing.)

The best way of getting GCC (and getting one that has been known to compile FS2 before) is to get Cygwin. GCC is one of the programs you can download from it's installer. (You'll need other stuff too, like the Direct X headers.) GCC also has it's own command line version of CVS you could use instead of WinCVS.

[Inquisitor]

Actually, the make file work in VS about a month or so ago, so it wasn;t linux specific

We need a new makefile champion, while penguin is on hiatus, any takers?

[EdrickV]

To quote a bit of the code/Makefile that I got when I did a CVS grab not too long ago:

LDLIBS = -L/usr/X11R6/lib -lSDL -lGL -lGLU -lpthread

CXXFLAGS = \
 -g \
 -I/usr/local/include/SDL \
 -I. \
 -fno-exceptions \
 -D_DEBUG -DNO_CD_CHECK -UNDEBUG \
 -DNO_DIRECT3D $(SOUND_DEF) $(JOYSTICK_DEF) $(NETWORK_DEF) $(OPENGL_DEF)

Looks pretty Linux (or at least Linux OpenGL port) specific to me. Managed to get it to compile under PS2Linux but not under Cygwin. I got the following:

In file included from globalincs/pstypes.h:241,
                 from anim/animplay.h:108,
                 from anim/animplay.cpp:187:
windows_stub/config.h:193: declaration of C function `void strlwr(char *)' confl
icts with
/usr/include/string.h:70: previous declaration `char * strlwr(char *)' here
In file included from graphics/grinternal.h:143,
                 from anim/animplay.cpp:193:
graphics/font.h:124: `NAME_MAX' was not declared in this scope
In file included from anim/animplay.cpp:196:
cfile/cfile.h:604: `NAME_MAX' was not declared in this scope
anim/animplay.cpp: In function `void anim_display_info(char *)':
anim/animplay.cpp:1177: `NAME_MAX' undeclared (first use this function)
anim/animplay.cpp:1177: (Each undeclared identifier is reported only once
anim/animplay.cpp:1177: for each function it appears in.)
anim/animplay.cpp:1179: `filename' undeclared (first use this function)
make: *** [anim/animplay.o] Error 1

Looking at the makefiles themselves, I think the new Makefile (replacing the old Code.mak) was written pretty much from scratch. The two don't even look similar in format. It also has Win32 specific stuff (like the stand alone server support) commented out.

Edit: Don't forget, the GCC support was a side effect of the OpenGL port, not a stated goal IIRC.

[Inquisitor]

I just no I was able to import it into Visual Studio and compile
Lemme do a diff on the laptop, I think I still have a version that works

Side effect or not, it was a good one, and one we want to keep.

Wanna fix it?

[EdrickV]

Fixing the makefile is beyond my ability. (And I bet the makefile you imported was the fs2_open.w32.mak file which is VC++ specific so won't work with GCC.) Thanks to a little MUSHCode I got a version of the old Makefile I had that now has all lowercase file/folder names, but I've been having a heck of a time with it. (No matter what I did I couldn't get it to find windows_stub/config.h for the definition of _MAX_PATH, which in turn is defined as PATH_MAX, which is nowhere to be found. Even putting a _MAX_PATH define into the animplay.cpp file doesn't help because now it complains first that it can't find direct.h (which I don't have) and then complains about "fd_set" and some other stuff causing problems with windows sockets. Other then the fact that whatever that is, is related to networking, I don't have a clue what it's talking about.

$ make
Makefile:398: warning: overriding commands for target `clean'
Makefile:394: warning: ignoring old commands for target `clean'

g++ -mno-cygwin -fvtable-thunks -DNDEBUG -O0  -DWIN32 -I/usr/include -I./ -Iwindows_stub -include "windows_stub/config.h" -include "globalincs/pstypes.h" -Idemo -Istarfield -Ipcxutils -Imodel -Igraphics -Ifireball -Ibmpman -Iinetfile -Istats -Iphysics -Imovie -Ihud -Icfile -Wall -Iexceptionhandler -Iui -Iplayerman -Inetwork -Iio -Ifreespace2 -Icmdline -fexceptions -I3dnow -Ivcodec -Ipopup -Iobject -Ijumpnode -Ifs2launch -g -Iweapon -Iradar -Iobserver -Ilighting -D_WINDOWS -Ilocalization -Irender -Iosapi -Ifred2 -Iship -DNDEBUG -Inebula -Icmeasure -U_DEBUG -Igamehelp -Icontrolconfig -fomit-frame-pointer -Imath -Igamesequence -Icutscene -finline-functions -Ipalman -Imenuui -Igamesnd -Idebris -I.. -Isndman -Iparse -Imission -Iglide -Idebugconsole -Ianim -Itgautils -Isound -Iparticle -Imissionui -Iglobalincs -Idirectx -Iasteroid -mcpu=pentium -D_M_IX86=500  -o cfile/cfile.o -c cfile/cfile.cpp

cfile/cfile.cpp:201: direct.h: No such file or directory
In file included from /usr/include/w32api/windows.h:96,
                 from cfile/cfile.cpp:202:
/usr/include/w32api/winsock2.h:96: warning: #warning "fd_set and associated macros have been defined in sys/types.      This may cause runtime problems with W32 sockets"
make: *** [cfile/cfile.o] Error 1

[Fry_Day]

Ack, you're all forgetting one point - DJGPP is a DOS compiler. Of course it won't frickin' compile windoze code,as it generates DOS 32bit code.
How about MinGW32?

[EdrickV]

I used Cygwin's GCC, which FS2 has been compiled under before. It can't handle the MFC stuff since it doesn't have the libraries, but with the Direct X 5 headers someone had supplied it was able to compile the FS2 exe. But until now I hadn't tried compiling it since before all the filenames were changed to lowercase. I haven't had much experience with makefiles so fixing the old, formerly working, makefile compatable with the current code is beyond my abilities. Changing the Linux one might be an option, but I don't know what should be there for the Windows version and I think I'm missing the Direct X 8 headers. (Part of that being the previously mentioned direct.h if my guess is right.)

Edit: The MFC stuff is in FRED2, and POFView so neither would work with GCC without major porting work.

[Inquisitor]

Ah, you are absolutely right, my mistake.

WHat happens when you try to use that file? penguin "heavily modified" it?

[penguin]

I'll look at the gcc version of the makefile tonight.

And yes, I'm still alive

[EdrickV]

Originally posted by Inquisitor
Ah, you are absolutely right, my mistake.

WHat happens when you try to use that file? penguin "heavily modified" it?

The log above where it is complaining about strlwr() is what I got using the Linux makefile in CVS.

[penguin]

Originally posted by EdrickV
Looks pretty Linux (or at least Linux OpenGL port) specific to me. Managed to get it to compile under PS2Linux but not under Cygwin. I got the following:
....
Edit: Don't forget, the GCC support was a side effect of the OpenGL port, not a stated goal IIRC.

Hrm.  Well, I wrote that makefile so that  *I* could build under Linux -- I didn't ever consider that anyone would use GCC on Win32, so it's my bad  There are a lot of assumptions in that makefile regarding what source files need to be included, etc., so I'm not surprised you had problems with it.  That make file is Linux-specific at this point, not just OpenGL-centric.  (When I wrote it, there were no goals, stated or otherwise )

Unfortunately there is no easy way to reconcile all of this -- a makefile that works OK under GCC will not work well on MSVC, or at least it won't have all the nice "workspace" features people seem to like.  We did go down that road for a little while (I hacked together an MSVC "external makefile") but it was not well received.

I think we'll have to settle on maintaining (at least) two parallel makefiles: one (a "project workspace") for MSVC/Win32, and another -- that would be more configurable -- for gcc in multiple environments (Linux, cygwin, OSX, whatever).  The GNU project has a suite of tools (Autoconf/Automake) to generate makefiles for a variety of systems, however, MSVC/Win32 is not one of them IIRC.  I don't know if it'll work under cygwin or not, but I seem to recall that it does.  Setting up a project in Autoconf/Automake can be hairy; like most GNU software, there are ten thousand options...

I didn't have time to do much in the way of correcting it tonight.

What I would like to do is have a common Makefile.am that could generate the Makefiles for Linux, cygwin, whatever, but that might be a decent sized effort.  In the interim, I'll try to separate the Linux specific stuff out of the existing Makefile, maybe fork it info Makefile.linux, Makefile.w32, etc.

Sorry I didn't get a chance to fix it tonight, but I should be able to get something workable going RSN, I don't have cygwin so I won't be able to test it though.