Backtrack on previous change that aimed to solve the wrong `share.h`
being included. It turns out it did not fix this issue. At the same time
it introduced relative header filenames and the need to include the same
headers differently depending on the source files' location, reducing
readability and editability.
Replace this method by re-adding curl's lib source directory to the
header path and addressing headers by the their full, relative name to
that base directory. Aligning with this method already used in src and
tests.
With these advantages:
- makes includes easier to read, recognize, grep, sort, write, and copy
between sources,
- syncs the way these headers are included across curl components,
- avoids the ambiguity between system `schannel.h`, `rustls.h` vs.
local headers using the same names in `lib/vtls`,
- silences clang-tidy `readability-duplicate-include` checker, which
detects the above issue,
Ref: https://clang.llvm.org/extra/clang-tidy/checks/readability/duplicate-include.html
- possibly silences TIOBE coding standard warnings:
`6.10.2.a: Don't use relative paths in #include statements.`
- long shot: it works well with concatenated test sources, for
clang-tidy-friendly custom unity builds. Ref: #20667
Slight downside: it's not enforced.
If there happens to be a collision between a local `lib/*.h` header and
a system one, the solution is to rename (possibly with its `.c`
counterpart) into the `curl_` namespace. This is also the method used by
curl in the past.
Also:
- curlx/inet_pton: reduce scope of an include.
- toolx/tool_time: apply this to an include, and update VS project
files accordingly. Also dropping unnecessary lib/curlx header path.
- clang-tidy: enable `readability-duplicate-include`.
Follow-up to 3887069c66#19676
Follow-up to 625f2c1644#16991#16949Closes#20623
After this patch curl requires targeting Vista or newer, and a toolchain
with Vista support.
Supported MSVC compilers (VS2010+) all support Vista:
- VS2012+ target Win8 (or later) by default.
- VS2010 targets Win7 by default.
Supported mingw-w64 versions (v3+) all support Vista:
- mingw-w64 v9+ target Win10 by default.
- mingw-w64 v8 and older target Server 2003 (~XP) by default.
After this patch it may be necessary to override the default Windows
target version to Vista (or newer) via:
autotools: `CPPFLAGS=-D_WIN32_WINNT=0x0600`
cmake: `-DCURL_TARGET_WINDOWS_VERSION=0x0600`
- mingw-w64 v6+ allow changing the default at toolchain build-time.
Notes:
- For non-MSVC, non-mingw-w64 toolchains, `if_nametoindex` needs to be
allowlisted in `curl_setup.h`, if they do support it.
Fixes#17985 (discussion)
Closes#18009
- Fix generate.bat "-clean" option.
- Change version template substitutes to match old files, eg go back to
using format version "11.00" instead of "11.0".
- Limit the vcxproj filters file types that are filtered to c, h, rc.
- Get rid of the tmpl extension from template files and add a README
to the tmpl directory explaining the purpose of the files.
- gitignore VCxx directories entirely rather than individual file types.
- Do not remove the VC directories during clean, instead remove just the
generated project files.
Removing the VC directories has the unwanted behavior of removing files
other than those generated. Visual Studio will generate its own
preference files (like if you have some debug arguments in your .suo)
and those files sit in the VC directories. We ignore those files since
they are the user's files and should not be deleted. Also the user may
have their own untracked files that we shouldn't be deleting.
Follow-up to 57d349fe which consolidated the project templates.
Assisted-by: Viktor Szakats
Closes https://github.com/curl/curl/pull/18412
The three projects (VC10, VC11, VC12) are identical except 5 repeated
strings in them. They also require running `generate.bat` before use,
to populate source files. Reduce the 3 almost identical projects to
a single template project and populate the repeated strings also via
`generate.bat`. This reduces the maintenance burden to a single copy of
the project files. Also saving 10000 LOCs.
Closes#18396
