Date: Thu, 9 Mar 2017 15:58:19 -0700 From: Warner Losh <imp@bsdimp.com> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: svn commit: r314654 - in head/cddl: lib/drti lib/libavl lib/libctf lib/libdtrace lib/libnvpair lib/libumem lib/libuutil lib/libzfs lib/libzfs_core lib/libzpool sbin/zfs sbin/zpool usr.bin/ctfconver... Message-ID: <CANCZdfo1t=8E-Zuz6J8vqVFf1cMwELNq6cuEn62tMd_ZRcjevA@mail.gmail.com> In-Reply-To: <c6c9075b-f592-4d64-5e9e-9f6f1343b6cd@FreeBSD.org> References: <201703042039.v24KdcDE078734@pdx.rh.CN85.dnsmgr.net> <c6c9075b-f592-4d64-5e9e-9f6f1343b6cd@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ redirected to arch@ ]]
On 3/4/17 3:39 PM, Rodney W. Grimes wrote:
> Idk, maybe I am to personally attached to the relative paths.. cause I
> had a major part in helping them all to work, or perhaps its my been
> burned by absolute paths that had to be reworked too many times in
> my past. But my gutt is telling me this change is Bad(tm).
OK. Reading through this entire thread, it looks like the general
consensus is to move to SRCTOP. Let me summarize the reasons.
To summarize: We have never used relative paths. The paths have always
been absolute. SRCTOP makes the paths shorter in the Makefile as well
as making it possible to move Makefiles around. These two very real
benefit have not been offset against any tangible reasons to not do
this. ${.CURDIR} has always been an absolute path, and the makefiles
have always used ${.CURDIR}/.../../blah to reach over to some place
else in the tree. But these "tree relative" absolute paths are the
worst of both worlds. They fossilize the locations of the Makefiles
because they can't only be moved to a limited number of places. They
bloat the paths needlessly which increases the output of the commands
(and also makes the deepest top directory you can build from
significantly shorter). There never was a good reason to use the
${.CURDIR}/.. construct other than SRCTOP simply never existed until
recently.
So unless people can articulate a coherent reason to not do this, I
plan on moving ahead on SRCTOP. This was the consensus of the folks
maintaining the build system before this commit and remains the
general (though not unanimous) consensus after the discussion.
The first of the code reviews is here, which try to duplicate the work
ngie@ did on the topic, but with only the SRCTOP changes for the
moment:
https://reviews.freebsd.org/D9932
There was a prior arch@ thread:
https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018117.html
which generated no objections as well, adding to my opinion that we
have consensus.
I'll do others for the rest of the tree and commit them in 'chunks'
the size of top-level components (or maybe smaller if those chunks are
too large, since it's better for external people to have 10 smaller
chunks to merge than 1 larger chunk). I hope to push this in sometime
next week.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo1t=8E-Zuz6J8vqVFf1cMwELNq6cuEn62tMd_ZRcjevA>