Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Mar 2017 20:50:40 -0800
From:      "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com>
To:        "freebsd-arch@freebsd.org" <arch@FreeBSD.org>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   SRCTOP/OBJTOP refactoring in ^/head
Message-ID:  <8787E0E4-CD5D-4E53-BDF4-5E0ED1FD7069@gmail.com>

next in thread | raw e-mail | index | archive | help

--Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,
	I=E2=80=99m posting an official follow up to the numerous =
commits I=E2=80=99ve 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- Makefile.inc        (revision 314827)
+++ Makefile.inc        (working copy)
@@ -1,3 +1,4 @@
-.if exists(${.CURDIR}/../../Makefile.inc)
-.include "${.CURDIR}/../../Makefile.inc"
-.endif
+FORTUNE_SRC=3D   ${SRCTOP}/usr.bin/fortune
+FORTUNE_OBJ=3D   ${OBJTOP}/usr.bin/fortune
+
+.include "${SRCTOP}/usr.bin/Makefile.inc=E2=80=9D

Index: fortune/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- fortune/Makefile    (revision 314827)
+++ fortune/Makefile    (working copy)
@@ -3,7 +3,7 @@

 PROG=3D  fortune
 MAN=3D   fortune.6
-CFLAGS+=3D-DDEBUG -I${.CURDIR}/../strfile
+CFLAGS+=3D-DDEBUG -I${FORTUNE_SRC}/strfile

 .include <bsd.prog.mk>

# ...

	Doing this has several benefits:
	1. The make output is more abbreviated because it=E2=80=99s 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 =E2=80=94 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=E2=80=99t care so much about MFCing changes=E2=80=A6=
 it=E2=80=99s pretty straightforward/mechanical and easier to test one =
directory at a time if possible).
	Questions, comments, and other things (as long as there aren=E2=80=
=99t too many torches/pitchforks) are more than welcome.
Thanks,
-Ngie

--Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYvjwhAAoJEPWDqSZpMIYV5GQP/iA1oelzKbcK8hvEbWM+6tsh
rQ8LEYy4t6JKNk6diwgrVvNazmuIidOVU7u1EWDuMH1e51C6iB8WDRUqSnz7EF65
V2tfcaQ49dxy2FvrGRt/o0G2C2IHfcHbtywIzMeGPhQ0LB1Rc+TmHOrDK+8wvPZx
4DHmktySn4YCp4jNXlGYMqkPdW8ateIlOuOxUqQg5WIBUkf0OmgPqsvPYzYfB08Z
fbY2GZAxIci91/488VyIyVKFRyPP/Fyt/Y9D5IEq4WPhx2Hav2cOVYePdUVjhlXD
1lpfX7WkpYXD/oY0Ul53lrCrgL2LzTa3irKBZu0+Do/Co4t2Uu3JJcsE3bbZ0gl+
jPNmx/D5tWgh9jazi07H3YNLoOjc08W7k61qp879qJaiCitpFI4Anrx4NuOWLPhe
7CehsIZQvMiXuo2RaK4L+5hzvJ0jCrlfZVKXI7zLSveo8ov4O591OITWHfWTEL2+
sq4+pi+Q9u7qU4wyiq0DcrhrfK5iD6RW8n1se/+UDl0B1LyRuZzJ6/MBT93L2iF+
/ZqqPadbGYKnQc+F59fQr3iCxZ+wrRUFXRgVGPb9K9gHQdJBVH7I1OcaT9xcGb97
VgLo5AJtUWu0VXLqaXTzMagmflhSOByZIKfv4DFsT3X2+YySnjVsp9Bl9zlsRsv4
SPJ2FIj9Qy11SRE/DP2e
=eFbb
-----END PGP SIGNATURE-----

--Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8787E0E4-CD5D-4E53-BDF4-5E0ED1FD7069>