We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Any platform where the code is checked out from CVS and then directly built from an IDE needs this.  (e.g. Win32, MacOS X Xcode, etc.)

Maybe we should generate an SDL_config_local.h that's never checked into CVS?

--ryan.

The trick is how do we know to include it?

Got it, I'll check it in shortly.

I take it back.

The trick is, if we check out and build under an IDE, then we want the default config for that platform.  But if we build using the configure method, then we want to use the generated header, overriding the default config.  We also need to know in applications which are built using SDL_config.h, which we ended up doing. :)

I'm open to suggestions...

How about this:

- Rename SDL_config.h.minimal to SDL_config_minimal.h
- Make the current #else section in SDL_config.h into an #elif defined(__SDL_MINIMAL__)
- Make a new #else section that includes SDL_config_local.h
- SDL_config_local.h is built by configure and installed with "make install"
- Platforms that don't use autoconf and don't have an explicit section in SDL_config.h can either be added where reasonable (#elif defined(__MY_EMBEDDED_PLATFORM__)), or force use of the minimal config header in their build system. Everyone else uses autoconf or something that can generate an SDL_config_local.h header.
- Never check SDL_config_local.h into CVS.
- Add SDL_config_local.h to .cvsignore.

Also, my assumption is that using the default minimal config is almost always an error, so it might be better to leave the SDL_config.h.minimal as a guideline, and let people deal with incorrectly falling into SDL_config_local.h as a platform-specific issue that's usually resolved with a new #elif in SDL_config.h.

That might be totally off the wall, but that's the best I've got right now.

--ryan.

I actually had this completely done and set up exactly this way and about to check in last night, when I realized that in this setup, the configure generated header would never override the default Win32 configuration when building SDL with gcc for Windows.

I'm stumped.

I just noticed the same issue and sent a mail to Sam before noticing we now have a Bugzilla (yay to that, BTW :-).

FYI, this is how I handled a very similar issue when I ported Exult to MacOS Classic (back in the good old days ;-):

Instead of having SDL_config_PLATFORM.h, use PLATFORM/SDL_config.h . Then, the default "unix" installer ignores these files (to this end, one may want to keep those outside the "include" dir, maybe in a new "dists" directory or so). The "unix" build is unchanged. All custom non-native build systems simply are changed to add their corresponding PLATFORM/ dir to the includ dir list at the front. And their installers simply install PLATFORM/SDL_config.h

Of course, for this to work the "install" method used by the custom build method must be powerful enough to install PLATFORM/SDL_config.h into the right place.

SDL_config.h is no longer in CVS.  Instead, configure will generate it for
systems that use configure, and we always copy SDL_config.h.default to
SDL_config.h before generating a snapshot or release archive.