Replace dot-dot relative pathing with SRCTOP/:H make manipulation where possible

[ngie]

Summary

Replace dot-dot relative pathing with SRCTOP/:H make manipulation where possible

I log my buildworlds and buildkernels with script, and have noticed
a lot of "../" scrolling by over time -- I'd prefer to get rid of
these so it writes less unnecessary characters to disk and slows down
my terminal output less

MFC after: 1 week
Sponsored by: Dell EMC Isilon

Test Plan

Before patch:

% make cleandir -j12; script all.ts time make all -j12 MK_TESTS=no
...
objcopy --strip-debug --add-gnu-debuglink=libc.so.7.debug  libc.so.7.full libc.so.7
      111.55 real       280.00 user        39.12 sys
% wc -c all.ts
 5118811 all.ts
%

Script done, output file is all.ts

After patch:

% make cleandir -j12; script all.ts time make all -j12 MK_TESTS=no
...
objcopy --strip-debug --add-gnu-debuglink=libc.so.7.debug  libc.so.7.full libc.so.7
      111.70 real       279.52 user        39.50 sys

Script done, output file is all.ts
% wc -c all.ts                                                                                                                                                           
 4836944 all.ts
%

(and that savings is with just regular make output -- I'm not using -d at all)

[ngie]

• Remove unrelated stdio.h diff
• Add lib/libc/resolv/Makefile.inc diff

[emaste]

Overall I like it. A few questions about :H vs ${SRCTOP}.

lib/libc/Makefile

39

Should this one be ${SRCTOP}/include? It looks like we intend to allow compiling libc from a different source location (i.e. LIBC_SCRTOP?= so referencing the system include via ${LIBC_SRCTOP} seems less desirable.

lib/libc/md/Makefile.inc

3

this one arguably should be ${SRCTOP}-based

[ngie]

Update based on feedback from emaste

[ngie]

lib/libc/Makefile

39

Agreed. r262722 seems like it's done in the vein of standardizing SRCTOP/OBJTOP, but for a very specific purpose that could instead be solved via SRCTOP universally now.

I CCed marcel though, just to be safe. I'll add sjg as well.

[emaste]

lib/libc/iconv/Makefile.inc

25

Perhaps this should be based on ${SRCTOP} too, in which case (with my other comment just added) we'll have no ${LIBC_SRCTOP}/.. left.

lib/libc/stdtime/Makefile.inc

5–6

Is this right? The path is lib/libc/locale no?

[marcel]

I don't want to assume I remember all the details with respect to compiling libc from a different locations, but what I recall is that it's only about building libc using a different makefile that lives in a different directory and thus having the object files go to a different object directory. Thus any mention of ${.CURDIR} had to be replaced with LIBC_SRCTOP and LIBC_SRCTOP was effectively set to ${SRCTOP}/lib/libc.

As such, I think it's fine to replace ${LIBC_SRCTOP:H} with ${SRCTOP}/lib, ${LIBC_SRCTOP:H:H} with ${SRCTOP}, and consequently any paths that start with one of those.

I recall that -I options needed to be tweaked, but those were prepended to CFLAGS from within the alternate makefile.

My general advise therefore is to not change semantics. Make it a mechanical bug-for-bug compatible change.
Thus replace ${LIBC_SRCTOP}/../locale with ${LIBC_SRCTOP:H}/locale or alternatively with ${SRCTOP}/lib/locale...

[sjg]

General point; using :H is preferable to ../ if only to speed up filesystem access.

As several comments above have already made reasonably clear, much of the ../../ references in the FreeBSD makefiles can be replaced with SRCTOP relative references, this not only makes the intend of the makefiles clearer but also aids tree refactoring.

AFAIK the prevelant use of ../.. references is largely a consequence of .CURDIR and .OBJDIR traditionally being the only known reference points.
With the advent of .PARSEDIR and the ability to reliably define SRCTOP, this is no longer the case, and considerable cleanup of the makefiles is possible.

[emaste]

My general advise therefore is to not change semantics. Make it a mechanical bug-for-bug compatible change.
Thus replace ${LIBC_SRCTOP}/../locale with ${LIBC_SRCTOP:H}/locale or alternatively with ${SRCTOP}/lib/locale...

I think it's probably reasonable to make this a mechanical change and not change semantics, but then I think we should either fix or drop the locale path first in an initial commit. lib/locale doesn't exist, so having it in .PATH doesn't do any good.

[ngie]

In D9207#191297, @emaste wrote:

My general advise therefore is to not change semantics. Make it a mechanical bug-for-bug compatible change.
Thus replace ${LIBC_SRCTOP}/../locale with ${LIBC_SRCTOP:H}/locale or alternatively with ${SRCTOP}/lib/locale...

I think it's probably reasonable to make this a mechanical change and not change semantics, but then I think we should either fix or drop the locale path first in an initial commit. lib/locale doesn't exist, so having it in .PATH doesn't do any good.

Agreed. I'll wait for you to commit your patch before I commit my larger one.

[ngie]

In D9207#191296, @sjg wrote:

General point; using :H is preferable to ../ if only to speed up filesystem access.

As several comments above have already made reasonably clear, much of the ../../ references in the FreeBSD makefiles can be replaced with SRCTOP relative references, this not only makes the intend of the makefiles clearer but also aids tree refactoring.

AFAIK the prevelant use of ../.. references is largely a consequence of .CURDIR and .OBJDIR traditionally being the only known reference points.
With the advent of .PARSEDIR and the ability to reliably define SRCTOP, this is no longer the case, and considerable cleanup of the makefiles is possible.

I agree 1000%.

[emaste]

LGTM with the changes discussed above

[ngie]

Apply review comments

[bdrewery]

+1