Cvs Won't Compile In Windows

[ttlanhil]

I first saw this a few days ago, still there in the latest cvs update (I last updated a minute ago)

 

line three of textures.c:

#include <unistd.h>

 

That's not available in windows (well, maybe if you use cygwin, but not for visual C.net, which is what I have)

 

because that file isn't there, the client won't compile at all

[Learner]

The #ifdef's need to be added so it still compiles under cygwin/dev-cpp properly while still compilnig under your box. The 'official' development platform on Windows is Dev-CPP, not Visual .NET or Visual C

 

Once you get it work, submit a patch to the berlios patches.

[Grum]

Fixed

[ttlanhil]

I tried just commenting that line out, but then I get an error that 'F_OK' is undefined.

adding the file in question from the 'net results in another file missing.

my C knowledge is pretty limited, it's not a language I've worked in yet.

 

I guess I could try getting dev-cpp as well, but I have to use VS.NET for uni anyway, so it was easier to use that

[ttlanhil]

Fixed

165216[/snapback]

whoo, thanks, I can run bleeding-edge CVS again!

[ttlanhil]

#include <unistd.h>

<snip>

// Grum: removed. if the file doesn't exist, (my_)fopen will catch it
// Wytter: Readded, we don't want 200000 file not found in errors.log...
if(access(filename, F_OK)) return 0;//File doesn't exist...

it was broken again, visual studios does not have unistd.h available

 

now that I've been through this before, I knew that I could comment the stuff out and it'd work again, but other people probably won't know why it broke again, depending on a system library that isn't there.

 

is there a way to do the checking that's more portable?

[Learner]

#include <unistd.h>

<snip>

// Grum: removed. if the file doesn't exist, (my_)fopen will catch it
// Wytter: Readded, we don't want 200000 file not found in errors.log...
if(access(filename, F_OK)) return 0;//File doesn't exist...

it was broken again, visual studios does not have unistd.h available

 

now that I've been through this before, I knew that I could comment the stuff out and it'd work again, but other people probably won't know why it broke again, depending on a system library that isn't there.

 

is there a way to do the checking that's more portable?

169803[/snapback]

Then submit a patch that will work for visual studio. The Windows development is normally done using Dev-cpp which does support those things.

[ttlanhil]

Then submit a patch that will work for visual studio. The Windows development is normally done using Dev-cpp which does support those things.

169804[/snapback]

if I did that, all it would do is #ifdef out the offending code, which means the error checking isn't done. that's the sort of thing I might do to code I use, but not submit for others

unfortunately I don't know enough C to be able to figure out what another method of doing the testing is (I was given visual studios because I have to do some visual basic at uni, not much C skill here yet)

[Wytter]

Sure, we can do a normal fopen instead - Things that makes you go "duh!"

Edited June 12, 2005 by Wytter

[Lhibou]

#ifdef WINDOWS

#include <stdio.h>

#define F_OK 0

#else

#include <unistd.h>

#endif

[crusadingknight]

#ifdef WINDOWS

#include <stdio.h>

#define F_OK 0

#else

#include <unistd.h>

#endif

171102[/snapback]

Well, since there are ways to restrict access on windows, I think it's best to stick with checking if we can fopen it instead.

[Learner]

#ifdef WINDOWS

#include <stdio.h>

#define F_OK 0

#else

#include <unistd.h>

#endif

171102[/snapback]

You don't want to limit it based on windows, instead it should be based on which compiler is being used. Under windows with dev-c++ the patch isn't needed.

 

FYI, you can limit access under windows, specially under XP & XP Pro, so you do want to have a test of some sort even if it is checking the results of the fopen.

[Wytter]

FYI that patch is not needed at all any more since it's just using a normal fopen, hence the duh!.

Edited June 16, 2005 by Wytter