Why do we have @ in modules builds?

[Bruce Evans]

On Mon, 3 Nov 2014, Warner Losh wrote:

> Does anybody recall why we have @ symlink in our module builds?
> I’m constantly working around issues that this creates. Maybe it is time
> to eliminate it?

It is probably because I finished implementing '@' for modules better than
for kernels.

wollman introduced '@', but didn't change config(8) to generate it.
My version of config does generate it, and I always use it for kernels,
but I never committed this.  My kernel object tree is under /usr/obj,
and my source tree is hacked to point to it.  E.g., /sys/i386/compile ->
/usr/obj/usr/src/sys/compile (should be to .../sys/i386/compile).  '@'
then points back to /usr/src/sys.

Modules have more varied paths than kernels, so @ is even more useful
for them.

-current (ref11-i386) also uses /usr/obj, but instead of '@' it uses:

% S=/usr/src/sys
% ...
% .if !defined(S)
% .if exists(./@/.)
% S=	./@
% .else
% S=	../../..
% .endif
% .endif
% .include "$S/conf/kern.pre.mk"
% 
% INCLUDES+= -I$S/contrib/libfdt

The default S wouldn't work at all.  Config doesn't support '@', but supports
'S' instead.  (It seems to only do this when necessary -- it doesn't do it
for my source-relative object trees on the same machine.)

The generated Makefile then uses $S throughout as before.  This hasn't changed
since at least wollman's change in ~1993.  Using $S instead of its expansion
keeps the makefile fairly readable.

The main advantage of '@' is that it reduces the unreadability of make
output and .depend files.  When '@' is used, $S expands to just "./@".
This keeps individual pathnames fairly short and makes it easier to see
the basenames.  $S might be much longer than the above, depending on the
depth of the source tree and on realpath-like expansion of symlinks.
make output remains fairly unreadable due to other spam in it.  The spam
that it used to have for -D options has been adequately replaced by spam
from -W options.

Without automatic generation of the paths, finding the path to the sources
is fragile.  To find the top level directory, kmod.mk still seems to just
search .., ../.., /sys and /usr/src/sys.  No trace of SRCDIR in the Aug 6
RELENG_11 version.  I think I wrote most of that.  It is better than
nothing.

Modularity is also very broken for programs.  Most programs now depend
on src.opts.mk, which doesn't exist for programs outside of the source
tree.  src.opts.mk sort of goes in the opposite and worse direction
than SRCDIR.  With a single source tree, you can hard-code SRCDIR in
a single file near src.opts.mk and not have to guess it.  Actually,
the mk directory is still hard to find.

Bruce