many people still build from the command-line using GNU Make, FWIW...
cr88192, on 12 Feb 2013 - 06:47, said:
PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files)
Adding linker/header paths to the IDE search directories is fairly standard practice and if you have to hard-code anything you’re doing it wrong.
If you are not using IDE’s and using makefiles directly, firstly, that’s just pain you are bringing onto yourself and you have no one else to blame. Secondly you can still use environment variables ($(DXSDK_DIR) would be a good one!) to avoid hard-coding paths.
If the fact that the Windows SDK and the DirectX SDK are separate (as they very-well should be) caused you even the slightest inconvenience, I think you need to gain a bit more experience in general programming, because linking to libraries is a fact of life in the world of programming. The concept of “search paths” exists whether you are using an IDE or raw makefiles, and every programmer should know about this at an early age.
Speaking for myself, my first word as a child was “Mamma”.
My second was “Chocolate cake”.
My third was “Search paths”.
this has the advantage that many core files for the project (much of the Makefile tree) can be shared between OS's.
(vs say a Visual Studio project, which is only really useful to Visual Studio...).
but, yes, although a person can get it linked, it is less convenient given it isn't kept along with all the other OS libraries.
like, in the top-level Makefile, a person may need something like:
export DXSDK="C:\\Program Files..."
as well as passing this back to CL as part of their CFLAGS and similar.
not that it can't be done, but a person can just as easily not do so, and instead just use core libraries (those provided by the Windows SDK for Windows builds, which happens to include OpenGL and the Win32 API, but not typically DirectX).
but, the bigger question is, how worthwhile is it to have a big dependency for something that is largely Windows-specific anyways (and can't really be used to any real non-trivial degree without putting portability at risk)?...