Viktor Szakats b563a92cd6 tidy-up: process.h detection and use ... This patch aims to cleanup the use of `process.h` header and the macro `HAVE_PROCESS_H` associated with it. - `process.h` is always available on Windows. In curl, it is required only for `_beginthreadex()` in `lib/curl_threads.c`. - `process.h` is also available in MS-DOS. In curl, its only use was in `lib/smb.c` for `getpid()`. But `getpid()` is in fact declared by `unistd.h`, which is always enabled via `lib/config-dos.h`. So the header is not necessary. - `HAVE_PROCESS_H` was detected by CMake, forced to 1 on Windows and left to real detection for other platforms. It was also set to always-on in `lib/config-win32.h` and `lib/config-dos.h`. In autotools builds, there was no detection and the macro was never set. Based on these observations, in this patch we: - Rework Windows `getpid` logic in `lib/smb.c` to always use the equivalent direct Win32 API function `GetCurrentProcessId()`, as we already did for Windows UWP apps. This makes `process.h` unnecessary here on Windows. - Stop #including `process.h` into files where it was not necessary. This is everywhere, except `lib/curl_threads.c`. > Strangely enough, `lib/curl_threads.c` compiled fine with autotools > because `process.h` is also indirecty included via `unistd.h`. This > might have been broken in autotools MSVC builds, where the latter > header is missing. - Delete all remaining `HAVE_PROCESS_H` feature guards, for they were unnecessary. - Delete `HAVE_PROCESS_H` detection from CMake and predefined values from `lib/config-*.h` headers. Reviewed-by: Jay Satiro Closes #9703		2022-11-01 22:27:28 +00:00
..
WindowsCache.cmake	tidy-up: process.h detection and use	2022-11-01 22:27:28 +00:00