preprocessor feature macros & Windows build options

[daniel.santos]

A few weeks ago silnarm made the case for having all feature preprocessor macros have a value instead of being defined or undefined and I agreed that this is a good idea.  I'm screwing with things now -- I just can't help myself!  In refactoring some of the Program code, I'm running into more things that can be further simplified.

Proposal 1: Add ${project_root}/sources/features.h
By ${project_root}, I mean where you check out your sources, so this will be under (or "above" depending upon how you look at it) the sub-directories containing the sub-projects in the source tree.  This will be one long series of this crap:

Code: [Select]

#ifndef DEBUG_WORLD
#   define DEBUG_WORLD=0
#endif

#ifndef USE_OPENAL
#   define USE_OPENAL=0
#endif

#ifndef USE_SOMETHING_ELSE
...

Then, we can just include features.h to before we do any tests against these and we'll have validated that they are setup correctly (or a compilation error will occur).

Proposal 2: Work towards Win32 & Linux being built against the same libraries.
There are a few (very few) number of cases where the Windows API offers something more powerful than SDL -- mostly on windows 64 bit with threading & IO functions.  Other than that, almost everything that we're using to build on linux is available on Windows.  Thus, I propose we move towards compiling under a common platform to further simplify the code.  This means the following libraries on Windows:

• OpenAL (instead of Direct Sound)
• SDL (instead of native Windows API calls)

The exceptions to this is, as far as I know right now is:

• High performance timers (i.e., greater than milliseconds).  SDL doesn't support these and we're using Windows-specific code to get them on Windows and POSIX and/or Linux-specific code to get them on Linux.
• Networking API
• Maybe boot strap code (currently on Windows, we're compiling as a windows console app and we may want to take it back to a regular windows app)

[hailstone]

Proposal 1:
I'm not sure why you would have #ifndef for each one. I'm thinking just have one for the whole header file and since we're only expecting these to be defined there it shouldn't be a problem. If any are defined somewhere else it should appear as a compiler warning?

Proposal 2:
I don't see why we can't use SDL and OpenAL for both and use the platform specific features where it makes sense. This is another major change, though. Do we have an up-to-date roadmap?

[daniel.santos]

I'm not sure why you would have #ifndef for each one...

So you only have to define the ones you want in your build script, or msvc++ project file, etc.

I don't see why we can't use SDL and OpenAL for both and use the platform specific features where it makes sense. This is another major change, though. Do we have an up-to-date roadmap?

Roadmap?  That sounds like a pretty good idea.  That's what I like about you hailstone, you help balance out my inherent randomness.

In the network branch I have changed some of this, but mostly just refactoring the sound & graphics factory classes so there isn't a separate .h & .cpp file for each platform.

[hailstone]

So you only have to define the ones you want in your build script, or msvc++ project file, etc.

Wouldn't this defeat the purpose of defining with 1 and 0?

You could also group the types:

Code: [Select]

#ifndef FEATURES_H
#define FEATURES_H

#define DEBUG_WORLD=0
#if DEBUG_WORLD
#   define DEBUG_WORLD_SUB1=0
#   define DEBUG_WORLD_SUB2=0
#   define DEBUG_WORLD_SUB3=0
#endif

#define USE_OPENAL=0

#endif


[silnarm]

So you only have to define the ones you want in your build script, or msvc++ project file, etc.

Wouldn't this defeat the purpose of defining with 1 and 0?

It is still defined with a 1 or 0, this only sets them to 0, if they aren't already defined (ie, in project settings).

The other bonus, this puts them all in one place, my earlier suggestion duplicates the list for windows and linux.

[daniel.santos]

Wouldn't this defeat the purpose of defining with 1 and 0?

hmm, I hadn't thought of that.  So the defining them as ones or zeros just to have them all in the build script/project huh?  That's indeed a thought. (Was that your point silnarm? )  But it also makes it easier to mix the pre-processor code with C++ code, like this:

Code: [Select]

if(DEBUG_WORLD) {
    // do some stuff
}
And when it's optimized (even minimally), it will be removed as dead code.  But also, you can set debug levels:

Code: [Select]

if(DEBUG_WORLD >2) {
    // do even more stuff
}

And yea, sub-options is a good idea too.  I had to rename it gae_features.h (which I wasn't too happy about) because it was conflicting with gcc libstdc++'s "features.h" for some stupid reason.   So here's what mine looks like thus far (and I'm still working out all of my compile errors after this last singleton massacre:

Code: [Select]

#ifndef USE_PTHREAD
# define USE_PTHREAD 0
#endif

#ifndef USE_SDL
# define USE_SDL 0
#endif

#ifndef USE_OPENAL
# define USE_OPENAL 0
#endif

#ifndef USE_DS8
# define USE_DS8 0
#endif

#ifndef USE_POSIX_SOCKETS
# define USE_POSIX_SOCKETS 0
#endif

#ifndef SL_LEAK_DUMP
# define SL_LEAK_DUMP 0
#endif

#ifndef USE_SSE_INTRINSICS
# define USE_SSE_INTRINSICS 0
#endif

#ifndef ALIGN_12BYTE_VECTORS
# define ALIGN_12BYTE_VECTORS USE_SSE_INTRINSICS
#endif

#ifndef ALIGN_16BYTE_VECTORS
# define ALIGN_16BYTE_VECTORS USE_SSE_INTRINSICS
#endif

#ifndef DEBUG_NETWORK
# define DEBUG_NETWORK 0
#endif

#ifndef DEBUG_NETWORK_DELAY
# define DEBUG_NETWORK_DELAY 0
#endif

#ifndef DEBUG_NETWORK_DELAY_VAR
# define DEBUG_NETWORK_DELAY_VAR 0
#endif

#ifndef DEBUG_WORLD
# define DEBUG_WORLD 0
#endif

#ifndef DEBUG_PATHFINDER
# define DEBUG_PATHFINDER 0
#endif

#ifndef DEBUG_TEXTURES
# define DEBUG_TEXTURES 0
#endif

#ifndef USE_xxxx
# define USE_xxxx 0
#endif

// Sanity checks
#if defined(DEBUG) && defined(NDEBUG)
# error "Don't set both DEBUG and NDEBUG in the same build please."
#endif

#if DEBUG_NETWORK_DELAY && !DEBUG_NETWORK
# error DEBUG_NETWORK_DELAY requires DEBUG_NETWORK to be set
#endif

#if USE_SSE_INTRINSICS && !(ALIGN_12BYTE_VECTORS && ALIGN_16BYTE_VECTORS)
# error if USE_SSE_INTRINSICS is set, then ALIGN_12BYTE_VECTORS and ALIGN_16BYTE_VECTORS must both be set.
#endif

Finally, it may already be possible to set USE_SDL and compile on windows, I'm not certain.  As I've been going back through a lot of this code, I've taken great care (in the past) to choose the defined(USE_SDL) option prior to defined(WIN32) || defined(WIN64), except in cases where the SDL facilities were weaker (threads & timers).  Also, I sure would like to get it working as a 64-bit Windows executable for Vista & Win7.  I have some code in shared_lib/*/platform/thread.h that I would want to validate as working that's for win64 only (the Shared::Platform::Condition class).

Lastly, I would also like to get pthread support working.  Honestly, I don't think I've even tried to do a test compile yet.   While I suppose it's not terribly important, it would give us a lot of capabilities in regards to:

• Being able to select on multiple objects that includes threads (as well as sockets).  This isn't a huge deal, but it would make my network thread's main loop slightly cleaner.
• Altering thread priority.  Whenever we get around to implementing multi-threaded support for core stuff like world-updates, rendering, etc., this would be helpful.

[daniel.santos]

Oh, silnarm, I think that maybe "DEBUG_TEXTURES" was the wrong thing to put.  All the code you added with the extra textures and World::loadPFDebugTextures() and such, that's to display the pathfinder on the map huh?  So I guess that should all be under DEBUG_PATHFINDER?  What do you want that to be called?  I should actually try that out huh?

[silnarm]

Wouldn't this defeat the purpose of defining with 1 and 0?

hmm, I hadn't thought of that.  So the defining them as ones or zeros just to have them all in the build script/project huh?  That's indeed a thought. (Was that your point silnarm? )  ....

Yeah, I was originally suggesting defining them via the 'build environment', so you need not worry about them being not defined. or having to include a certain header... but if it gets pulled into the precompiled header that shouldn't be a problem, so I kind of like your idea better.

Oh, silnarm, I think that maybe "DEBUG_TEXTURES" was the wrong thing to put.  All the code you added with the extra textures and World::loadPFDebugTextures() and such, that's to display the pathfinder on the map huh?  So I guess that should all be under DEBUG_PATHFINDER?  What do you want that to be called?  I should actually try that out huh?

My collection atm:

Code: [Select]

DEBUG_RENDERING_ENABLED=1
DEBUG_SEARCH_OVERLAYS=0
DEBUG_RENDERER_VISIBLEQUAD=0
DEBUG_SEARCH_TEXTURES=0
DEBUG_VISIBILITY_OVERLAY=1

DEBUG_SEARCH_TEXTURES is what I'm calling that one now.  It's also been cleaned up somewhat in the pathfinder branch, so there's a few less conditionally compiled blocks. [of course it probably also doesn't work in the pathfinder branch atm but I'll be needing them again soon, so they'll have to be fixed at some point...]