YP is less and less used, split them to users have the choice to not
install them.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33441
(cherry picked from commit 5abb10faa1)
This is mostly two problems spread out far and wide:
- ypldap_process should be declared properly
- debug is defined differently in many programs
For the latter, just extern it and define it everywhere that actually needs
it. This mostly works out nicely for ^/libexec/ypxfr, which can remove the
assignment at the beginning of main in favor of defining it properly.
-fno-common will become the default in GCC10/LLVM11.
MFC after: 3 days
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Initially, only tag files that use BSD 4-Clause "Original" license.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D13133
These are no longer needed after the recent 'beforebuild: depend' changes
and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports
skipping 'make depend'.
Sponsored by: EMC / Isilon Storage Division
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
messy way, so as to not disrupt other yp programs: just add casts to
convert the incompatible enums, as the numerical values are the same
(either by accident, design, or the phase of the moon at that time).
MFC after: 1 week
Just like bin/ and sbin/, I think setting WARNS to the highest value
possible will make it more attractive for people to fix warnings.
- The WARNS variable is set in the Makefile in the directory of the
application itself, making it more likely that it will be removed out
of curiosity to see what happens.
- New applications will most likely build with WARNS=6 out of the box,
because the author would more likely fix the warnings during
development than lower WARNS.
Unfortunately almost all apps in libexec require a lowered value of
WARNS.
