NAK. "inc/". (This also applies to Dependencies #3)
<rant>You should stick with facts, not opinions because this is just pedantic. MinGW uses include, TRoS (the TE gfx engine) uses include. Not every friggin directory needs to be three letters.</rant>Sorry...
Actually, now that I think about it some more, headers should generally go in the same directory as the files that #include them. They are, after all, part of the source.
The one major exception to this rule is found in Patch's directory structure. The assembly code is split (for good reason) into two directories: patches/ and procs/. When files from both directories need the same header, it can be found in inc/. However, when the header is specific to files in patches/, the include will also be found in patches/, not in inc/.
The general rule, IMO, is "Use ./ whenever possible. If that is not possible, use $PROJECT_ROOT/inc/." There are, of course, exceptions: Patch's inc/imports/ and Open's tables/ directories come immediately to mind.
It's a hassle to have to type '#include "../include/file.h"' instead of '#include "file.h"'. Obviously, if the project config/Makefile/&c. is such that ../include/ is in the header search path, this becomes a non-issue.
I probably wasnt 100% clear about the config stuff but I have no objection to using the defines to remove things. My objection is using them just to get the friggin thing to compile.
Of course. Assuming the presence of a competent shell, typing "./configure && make" (or, if the project is set up this way, just "make") should either give you a sane error message, such as "no compiler found, aborting", or a binary. Having to read READMEs or futz around for make onlythebinaryanddonotinstallit is suboptimal.
B) Some platforms (such as Windows) provide non-standard signatures for some functions. (mkdir comes to mind. POSIX specifies two arguments. Windows specifies one.) A macro may be used to ensure the correct number of arguments are specified, but behind the macro must lie some #ifdef that determines the POSIX-compliance of the platform.
I thought the environment you are in is automatically defined?
IIRC, the #definition of _WIN32, under Cygwin, is not sufficient to determine which of the following two lines will compile: (Exactly one will compile, but which one depends on the presence or absence of -m[no-]cygwin)
mkdir("temp"); // link directly to win32 libraires and dlls
mkdir("temp", 0755); // POSIX environments, including linking to cygwin1.dll
In either case the intention is to use libraries which have already sorted all this crap out.
I believe boost::filesystem does this. I wrote NFORenum's directory-handling-code long before I discovered Boost, and have no intention of rewriting something that works just to take advantage of a library I don't need.
Partial ACK. Makefiles can quite easily be placed wherever you please. Why do they get special status, unless they are, in fact, the de facto standard?
99.99% of projects I have seen are littered with Makefiles, I don't see why this one was going to be any different. But hey, if they can be put in one spot then we should do that.
They can be put in one spot, but this is rare. As XeryusTC points out, this causes them to be huge. The more pressing problem is that "make" may not do the expected thing if $PROJECT_ROOT does not contain a Makefile. I might consider changing this so that all build scripts and project files, for all IDEs, go in $PROJECT_ROOT. This causes a few minor problems with MSVS 7.1 vs MSVS 8.0, which use subtly different formats for their files, but still want to call them by the same names, but forcing a different name is an easy, one-time, procedure.