Re: A style proposal for referring to upper-level directories in Makefiles
In message 4e31aed9.4000...@aldan.algebra.com, Mikhail T. writes:
The most common method to refer to the upper directory in Makefile is as
${.CURDIR}/..
I'd like to propose we begin using ${.CURDIR:H} instead.
This will make it even harder for people who try to compile our
bits on alien systems without bmake.
I am not sure if that is a concern we should care about.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
On 29.07.2011 03:27, Poul-Henning Kamp wrote: This will make it even harder for people who try to compile our bits on alien systems without bmake. Bits referring to multiple directories at once? Using a make flavor, that already supports .CURDIR, but not .CURDIR:H? Do such things even exist? Personally, when I need to build a sizable BSD program on another system, I begin with building bmake (NetBSD's pkgsrc project helps with that). Or, if it is not a big program, I just create a GNUmakefile from scratch -- gmake is omnipresent these days. I am not sure if that is a concern we should care about. I don't think, we should either... -mi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
To me, it just makes things less readable. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
A style proposal for referring to upper-level directories in Makefiles
The most common method to refer to the upper directory in Makefile is as
${.CURDIR}/..
I'd like to propose we begin using ${.CURDIR:H} instead. For one this speeds up
the filesystem-traversal for the invoked tool. And, perhaps more importantly, it
makes the various build-logs look nicer (and be smaller). The lines in Makefiles
will also be shorter (two characters per level instead of three). For example:
--- secure/Makefile.inc 3 Aug 2009 08:13:06 - 1.25.10.1
+++ secure/Makefile.inc 28 Jul 2011 18:45:52 -
@@ -3,8 +3,8 @@
.include bsd.own.mk
-.if exists(${.CURDIR}/../../lib/libcrypt/obj)
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj
+.if exists(${.CURDIR:H:H}/lib/libcrypt/obj)
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj
.else
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt
.endif
@@ -14,4 +14,4 @@
.if ${MK_OPENSSH} != no
-SSHDIR=${.CURDIR}/../../../crypto/openssh
+SSHDIR=${.CURDIR:H:H:H}/crypto/openssh
.endif
The new method is functionally equivalent to the old and I see no drawbacks to
it, do you?
-mi
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
On 28 July 2011 19:47, Mikhail T. mi+t...@aldan.algebra.com wrote:
The most common method to refer to the upper directory in Makefile is as
${.CURDIR}/..
I'd like to propose we begin using ${.CURDIR:H} instead. For one this speeds
up the filesystem-traversal for the invoked tool. And, perhaps more
importantly, it makes the various build-logs look nicer (and be smaller).
The lines in Makefiles will also be shorter (two characters per level
instead of three). For example:
--- secure/Makefile.inc 3 Aug 2009 08:13:06 - 1.25.10.1
+++ secure/Makefile.inc 28 Jul 2011 18:45:52 -
@@ -3,8 +3,8 @@
.include bsd.own.mk
-.if exists(${.CURDIR}/../../lib/libcrypt/obj)
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj
+.if exists(${.CURDIR:H:H}/lib/libcrypt/obj)
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj
.else
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt
.endif
@@ -14,4 +14,4 @@
.if ${MK_OPENSSH} != no
-SSHDIR= ${.CURDIR}/../../../crypto/openssh
+SSHDIR= ${.CURDIR:H:H:H}/crypto/openssh
.endif
The new method is functionally equivalent to the old and I see no drawbacks
to it, do you?
-mi
Not too convinced I'm afraid-- in the logs I can at least see at a
glance where ${CURDIR} is, and how many directories it's traversing
etc etc.
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
On Thu, Jul 28, 2011 at 11:47 AM, Mikhail T. mi+t...@aldan.algebra.com wrote:
The most common method to refer to the upper directory in Makefile is as
${.CURDIR}/..
I'd like to propose we begin using ${.CURDIR:H} instead. For one this speeds
up the filesystem-traversal for the invoked tool. And, perhaps more
importantly, it makes the various build-logs look nicer (and be smaller).
The lines in Makefiles will also be shorter (two characters per level
instead of three). For example:
--- secure/Makefile.inc 3 Aug 2009 08:13:06 - 1.25.10.1
+++ secure/Makefile.inc 28 Jul 2011 18:45:52 -
@@ -3,8 +3,8 @@
.include bsd.own.mk
-.if exists(${.CURDIR}/../../lib/libcrypt/obj)
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj
+.if exists(${.CURDIR:H:H}/lib/libcrypt/obj)
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj
.else
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt
.endif
@@ -14,4 +14,4 @@
.if ${MK_OPENSSH} != no
-SSHDIR= ${.CURDIR}/../../../crypto/openssh
+SSHDIR= ${.CURDIR:H:H:H}/crypto/openssh
.endif
The new method is functionally equivalent to the old and I see no drawbacks
to it, do you?
This might cause issues with symlink traversal (it's the one thing
that came to mind). It wouldn't be a standard way to do things, but it
could cause problems if this change was made.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
