Another way to create a project with the proper settings is just to clone an existing project, remove the old sources, and add your new sources in.
A great example of a working project with lovingly-tuned settings (and shared configuration files) is DSP Filters in my signature. In XCode it builds correctly for all iOS and MacOSX targets, and has shared settings. Under both Visual Studio 2008 and 2010 it also builds for 32 bit or 64 bit. If you download the Android SDK, the same Visual Studio 2010 project will work (you just need to add a target).
The only thing missing is the X-Windows/GNU/Linux version, which is a very small percentage - but coming soon.
The build settings in DSP Filters using .xcconfig files in XCode and Property Sheets in Visual Studio (both 2008 and 2010). What this means is that you can have a SINGLE group of build settings applied across the board to multiple projects. The DSP Filters application is a perfect working example, it consists of three projects: the demo application, the DSP Filters static library, and the Juce amalgamated standard library. The same setup is used under both XCode and Visual Studio. All three projects have shared settings. Change a setting in the Property Sheet or XCode shared settings, and they are applied to everything.
Note that these shared properties are edited using the NATIVE IDE and not by modifying the files manually. In Visual Studio this is done with the Properties floating palette, and under XCode the configurations show up as additional columns in the graphical build settings.
So, an alternative to using IntroJucer is to just make a renamed copy of the appropriate DSP Filters projects, and drop your source files in there. I mean, is adding source files such a significant value-add that we need a separate application to do it? Me personally, I prefer the power of shared project settings and hand-tuning the project file taking full advantage of the features of each particular build environment instead of the lowest common denominator that Bruce pointed out.
But it should not be an either / or proposition - as long as IntroJucer is not REQUIRED to build the Juce library, and we do not go overboard obfuscating the Juce source tree with obscure macros and include schemes, we can accomodate both schemes; As well as any yet-to-be imagined schemes that some enterprising person might invent in the future.