We have a C++ template library that has some features that depend on zlib, for example.
We selectively enable and disable features using preprocessor symbols, i.e. setting -DHAVE_ZLIB=1 on the command line.
Our CMake-based build system recognizes installed zlib and adds the according flag to the compiler.
Of course, this can also be done manually by users, using their favourite IDE or their Makefiles.
One property of the library is that the code that uses zlib is interleaved with the code not using zlib, i.e. using #include <library/header.h> should work regardless of zlib being present or not.
Currently, we #if out code that depends on zlib.
Thus, if the user tries to use something like CompressedStream, for example, the class is simply not found.
This is quite frustrating for users.
The build system warns them that zlib could not be found, but users being users either do not see this or forget it quickly.
I myself have fallen into this trap, too.
Now to my question:
What is the best way to warn the user that zlib is disable if he tries to use code requiring zlib.
The only thing I can think of is using the deprecator marker mechanisms implemented in many compilers.
Although different syntax is required for each of them, this could easily be abstracted away using preprocessor macros.
Is there any other good way?
The solution only has to work in VS >8, GCC >4.2 and LLVM.
The proper place to warn users about such things is (IMO) build system. Take a look at Ogre3D, KDE and many other projects – all of them print sort of outline after configuration of build. This outline contains information on what is found and what is not and what are consequences of this.
Even Qt don’t do anyting to fix this. There is option to build Qt with STL support and if it’s not built such way, there are no warnings or whatever, only compile errors regarding undefined methods. So, i think, there is no way to warn user about such things during compile phase.