There is a minor change - after this, the macos man pages are also
installed into the /usr/local PREFIX. This seems like the correct
location to me.
Longer term, the usual autotools process of installing everything into
/usr/local should be used. Files installed in /usr should be done by
a package management tool, so this default makes sense to use.
Not all struct sockaddr are going to have the sa_family as their first field.
Since there is a named structure member, we can simply use that and let
the compiler sort it out.
This fixes a bug with at least FreeBSD and allows us to remove the
special case for Apple.
Some versions of autoconf (eg, the one included with Ubuntu 20.04 -
which is GNU Autoconf 2.69) will produce a configure script that
requires finding the install-sh script in either a short list of parent
directories or the defined AUX_DIR (This new requirement was probably
triggered by the use of the cross-compile features in configure.ac)
Newer versions flexibly identify which of the support scripts are
actually needed (from the list of config.guess, config.sub, install-sh)
and only check for those ones that are needed.
When the `./autogen.sh` runs `autoreconf -i`, it should have copied the
required aux scripts, but for some reason this is not happening.
Once we are not supporting the older autoconf, we should revisit this
config option as these auxiliary scripts should normally not be checked
into a version control system, for the same reasons that configure
shouldn’t be. For now, we ensure that all three scripts are available
and we have set the AC_CONFIG_AUX_DIR() to point to them
If the older autoconf is used, it will report the error:
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
Which is included here for search engines.
As suggested in a PR from @Legend-Master (this change is basically
unrelated to the main point of his PR, so extracted here)
Windows is a confusing and disappointing development environment. They
completely replaced all the definitions in winsock.h with exact
equivalents in winsock2.h (except for a small number of deprecated
functions).
However they didnt make them mutually exclusive - so if you include
both, you get errors. They also automatically include winsock.h from
windows.h, so you must remember to include winsock2.h first. They also
didnt just remove winsock.h and replace it with the new contents.
(Probably in the name of "compatibility", whilst swearing that the new
winsock is the same as the old one - because if you cannot believe two
inconsistent things simultaneously, you shouldnt be a windows
programmer)
All these things are totally nuts. Thanks, windows dev environment,
for not noticing that this is nuts
Refactor to "include-what-you-use"
This patchset aims to make future refactoring and cleanups simpler by ensuring that each file includes what it uses - see https://include-what-you-use.org/ for some more details about this concept and the tool used to help perform the refactoring.
No functional change is intended or expected and all tests are passing.
The include-what-you-use tool is awkward to use with the current state of the build system - and will always be difficult to use in a multi-platform safe way. However, I hope to provide a non manual process for running with the tool in the future.
There is still cleanup work to be done in the headers, but this
concludes the major include-what-you-use refactoring. No functional
change is intended or expected and all tests are passing.
It is now a lot easier to see what is used from each header and work on
possible refactoring in the future.
The include-what-you-use tool is awkward to use with the current state
of the build system - and will always be difficult to use in a
multi-platform safe way. However, I hope to provide a non manual
process for running with the tool in the future.
