Handling build options

The curl and libcurl source code has been carefully written to build and runon virtually every computer platform in existence. This can only be donethrough hard work and by adhering to a few guidelines (and, of course, a fairamount of testing).

A golden rule is to always add #ifdefs that checks for specific features, andthen have the setup scripts (configure or CMake or hard-coded) check for thepresence of said features in a user's computer setup before the program iscompiled there. Additionally and as a bonus, thanks to this way of writing thecode, some features can be explicitly turned off even if they are present inthe system andcould be used. Examples of that would be when users want to,for example, build a version of the library with a smaller footprint or withsupport for certain protocols disabled, etc.

The project sometimes uses #ifdef protection around entire source files when,for example, a single file is provided for a specific operating system orperhaps for a specific feature that is not always present. This is to make itpossible for all platforms to always build all files—it simplifies the buildscripts and makefiles a lot. A file entirely #ifdefed out hardly adds anythingto the build time, anyway.

Rather than sprinkling the code with #ifdefs, to the extent where it ispossible, we provide functions and macros that make the code look and work thesame, independent of present features. Some of those are then empty macros forthe builds that lack the features.

Both TLS handling and name resolving are handled with an internal API thathides the specific implementation and choice of 3rd party softwarelibrary. That way, most of the internals work the same independent of whichTLS library or name resolving system libcurl is told to use.