Ngie Cooper (yaneurabeya)
2017-03-07 04:50:40 UTC
Hi,
Iâm posting an official follow up to the numerous commits Iâve been doing on ^/head to convert paths in Makefiles from .CURDIR/.OBJDIR-relative paths to source (SRCTOP) / object (OBJTOP) tree relative paths, e.g., like the following make snippet,
$ svn diff | less
# ...
Index: Makefile.inc
===================================================================
--- Makefile.inc (revision 314827)
+++ Makefile.inc (working copy)
@@ -1,3 +1,4 @@
-.if exists(${.CURDIR}/../../Makefile.inc)
-.include "${.CURDIR}/../../Makefile.inc"
-.endif
+FORTUNE_SRC= ${SRCTOP}/usr.bin/fortune
+FORTUNE_OBJ= ${OBJTOP}/usr.bin/fortune
+
+.include "${SRCTOP}/usr.bin/Makefile.incâ
Index: fortune/Makefile
===================================================================
--- fortune/Makefile (revision 314827)
+++ fortune/Makefile (working copy)
@@ -3,7 +3,7 @@
PROG= fortune
MAN= fortune.6
-CFLAGS+=-DDEBUG -I${.CURDIR}/../strfile
+CFLAGS+=-DDEBUG -I${FORTUNE_SRC}/strfile
.include <bsd.prog.mk>
# ...
Doing this has several benefits:
1. The make output is more abbreviated because itâs now normalized to SRCTOP/OBJTOP.
i. This benefits tools that take paths literally, like Jenkins (it helped reduce the warning count by ~1,500 warnings in r312513 because Jenkins was double-counting warnings for sys/modules/ath ).
ii. Logfiles will be smaller, which means that data retention stress from CI services like Jenkins and Travis CI will be reduced.
iii. Less required I/O, which means:
I. This reduces needed bandwidth when transmitting the build output
II. Speeds up terminal output.
III. Reduces unnecessary writing to disk.
2. It makes it easier for humans to understand the layout of the tree.
3. It makes it easier for humans/vendors to build on/customize the components, instead of copy-pasting entire Makefiles and having to keep them up-to-date, e.g., allows me for instance to .include usr.sbin/syslogd/Makefile from foo/bar/syslogd/Makefile .
Some of my changes I introduced previously manipulated .CURDIR/.OBJDIR with the :H operator (strip one component, e.g., foo/bar/baz.c -> foo/bar ). I had 3 individuals (bdrewery, imp, rgrimes) ask for me to replace all :H uses I introduced in my refactoring with SRCTOP/OBJTOP paths (I completely agree with the requests â I was just trying to keep the spirit of the original Makefiles intact).
I will likely go back to committing by individual subdirectories as the approach I took this past weekend (based on a suggestion from rgrimes about not committing one directory at a time) was met with some complaints from users about downstream vendors/projects dealing with merge conflicts (I donât care so much about MFCing changes⊠itâs pretty straightforward/mechanical and easier to test one directory at a time if possible).
Questions, comments, and other things (as long as there arenât too many torches/pitchforks) are more than welcome.
Thanks,
-Ngie
Iâm posting an official follow up to the numerous commits Iâve been doing on ^/head to convert paths in Makefiles from .CURDIR/.OBJDIR-relative paths to source (SRCTOP) / object (OBJTOP) tree relative paths, e.g., like the following make snippet,
$ svn diff | less
# ...
Index: Makefile.inc
===================================================================
--- Makefile.inc (revision 314827)
+++ Makefile.inc (working copy)
@@ -1,3 +1,4 @@
-.if exists(${.CURDIR}/../../Makefile.inc)
-.include "${.CURDIR}/../../Makefile.inc"
-.endif
+FORTUNE_SRC= ${SRCTOP}/usr.bin/fortune
+FORTUNE_OBJ= ${OBJTOP}/usr.bin/fortune
+
+.include "${SRCTOP}/usr.bin/Makefile.incâ
Index: fortune/Makefile
===================================================================
--- fortune/Makefile (revision 314827)
+++ fortune/Makefile (working copy)
@@ -3,7 +3,7 @@
PROG= fortune
MAN= fortune.6
-CFLAGS+=-DDEBUG -I${.CURDIR}/../strfile
+CFLAGS+=-DDEBUG -I${FORTUNE_SRC}/strfile
.include <bsd.prog.mk>
# ...
Doing this has several benefits:
1. The make output is more abbreviated because itâs now normalized to SRCTOP/OBJTOP.
i. This benefits tools that take paths literally, like Jenkins (it helped reduce the warning count by ~1,500 warnings in r312513 because Jenkins was double-counting warnings for sys/modules/ath ).
ii. Logfiles will be smaller, which means that data retention stress from CI services like Jenkins and Travis CI will be reduced.
iii. Less required I/O, which means:
I. This reduces needed bandwidth when transmitting the build output
II. Speeds up terminal output.
III. Reduces unnecessary writing to disk.
2. It makes it easier for humans to understand the layout of the tree.
3. It makes it easier for humans/vendors to build on/customize the components, instead of copy-pasting entire Makefiles and having to keep them up-to-date, e.g., allows me for instance to .include usr.sbin/syslogd/Makefile from foo/bar/syslogd/Makefile .
Some of my changes I introduced previously manipulated .CURDIR/.OBJDIR with the :H operator (strip one component, e.g., foo/bar/baz.c -> foo/bar ). I had 3 individuals (bdrewery, imp, rgrimes) ask for me to replace all :H uses I introduced in my refactoring with SRCTOP/OBJTOP paths (I completely agree with the requests â I was just trying to keep the spirit of the original Makefiles intact).
I will likely go back to committing by individual subdirectories as the approach I took this past weekend (based on a suggestion from rgrimes about not committing one directory at a time) was met with some complaints from users about downstream vendors/projects dealing with merge conflicts (I donât care so much about MFCing changes⊠itâs pretty straightforward/mechanical and easier to test one directory at a time if possible).
Questions, comments, and other things (as long as there arenât too many torches/pitchforks) are more than welcome.
Thanks,
-Ngie