mirror of
https://github.com/moparisthebest/curl
synced 2025-02-28 17:31:46 -05:00

This commit renames lib/setup.h to lib/curl_setup.h and renames lib/setup_once.h to lib/curl_setup_once.h. Removes the need and usage of a header inclusion guard foreign to libcurl. [1] Removes the need and presence of an alarming notice we carried in old setup_once.h [2] ---------------------------------------- 1 - lib/setup_once.h used __SETUP_ONCE_H macro as header inclusion guard up to commit ec691ca3 which changed this to HEADER_CURL_SETUP_ONCE_H, this single inclusion guard is enough to ensure that inclusion of lib/setup_once.h done from lib/setup.h is only done once. Additionally lib/setup.h has always used __SETUP_ONCE_H macro to protect inclusion of setup_once.h even after commit ec691ca3, this was to avoid a circular header inclusion triggered when building a c-ares enabled version with c-ares sources available which also has a setup_once.h header. Commit ec691ca3 exposes the real nature of __SETUP_ONCE_H usage in lib/setup.h, it is a header inclusion guard foreign to libcurl belonging to c-ares's setup_once.h The renaming this commit does, fixes the circular header inclusion, and as such removes the need and usage of a header inclusion guard foreign to libcurl. Macro __SETUP_ONCE_H no longer used in libcurl. 2 - Due to the circular interdependency of old lib/setup_once.h and the c-ares setup_once.h header, old file lib/setup_once.h has carried back from 2006 up to now days an alarming and prominent notice about the need of keeping libcurl's and c-ares's setup_once.h in sync. Given that this commit fixes the circular interdependency, the need and presence of mentioned notice is removed. All mentioned interdependencies come back from now old days when the c-ares project lived inside a curl subdirectory. This commit removes last traces of such fact.
_ _ ____ _ ___| | | | _ \| | / __| | | | |_) | | | (__| |_| | _ <| |___ \___|\___/|_| \_\_____| Include files for libcurl, external users. They're all placed in the curl subdirectory here for better fit in any kind of environment. You must include files from here using... #include <curl/curl.h> ... style and point the compiler's include path to the directory holding the curl subdirectory. It makes it more likely to survive future modifications. NOTE FOR LIBCURL HACKERS The following notes apply to libcurl version 7.19.0 and later. * The distributed curl/curlbuild.h file is only intended to be used on systems which can not run the also distributed configure script. * The distributed curlbuild.h file is generated as a copy of curlbuild.h.dist when the libcurl source code distribution archive file is originally created. * If you check out from git on a non-configure platform, you must run the appropriate buildconf* script to set up curlbuild.h and other local files before being able of compiling the library. * On systems capable of running the configure script, the configure process will overwrite the distributed include/curl/curlbuild.h file with one that is suitable and specific to the library being configured and built, which is generated from the include/curl/curlbuild.h.in template file. * If you intend to distribute an already compiled libcurl library you _MUST_ also distribute along with it the generated curl/curlbuild.h which has been used to compile it. Otherwise the library will be of no use for the users of the library that you have built. It is _your_ responsibility to provide this file. No one at the cURL project can know how you have built the library. * File curl/curlbuild.h includes platform and configuration dependent info, and must not be modified by anyone. Configure script generates it for you. * We cannot assume anything else but very basic compiler features being present. While libcurl requires an ANSI C compiler to build, some of the earlier ANSI compilers clearly can't deal with some preprocessor operators. * Newlines must remain unix-style for older compilers' sake. * Comments must be written in the old-style /* unnested C-fashion */ To figure out how to do good and portable checks for features, operating systems or specific hardwarare, a very good resource is Bjorn Reese's collection at http://predef.sf.net/