From 0a9be94096289bd033f17370fb305f036ae086eb Mon Sep 17 00:00:00 2001 From: Gabor Pali Date: Wed, 11 Aug 2010 19:37:15 +0000 Subject: [PATCH] - Improve text on RUN_DEPENDS PR: docs/149480 Submitted by: sahil --- .../books/porters-handbook/book.sgml | 37 ++++++++----------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/en_US.ISO8859-1/books/porters-handbook/book.sgml b/en_US.ISO8859-1/books/porters-handbook/book.sgml index 51f058e47d..9431d62fe6 100644 --- a/en_US.ISO8859-1/books/porters-handbook/book.sgml +++ b/en_US.ISO8859-1/books/porters-handbook/book.sgml @@ -3283,33 +3283,28 @@ ALWAYS_KEEP_DISTFILES= yes part can be omitted if it is the same as DEPENDS_TARGET. - Quite common situation is when + A quite common situation is when RUN_DEPENDS is literally the same as BUILD_DEPENDS, especially if ported software is written in a scripted language or if it requires - the same run-time environment used to build it. In this - case, it is very tempting, and indeed natural to directly - assign one to another: + the same build and run-time environment. In this + case, it is both tempting and intuitive to directly + assign one to the other: RUN_DEPENDS= ${BUILD_DEPENDS} - However, doing so can and often will result in - run-time dependencies be polluted by superfluous entries, not - present in original port's BUILD_DEPENDS. - It happens due to the fact that &man.make.1 is being lazy - when it evaluates assignments like these. Most probably - additional dependencies will be pulled by - ports/Mk/bsd.*.mk when processing - USE_* - variables, which most ports contain. For example, such - direct assignment along with - USE_GMAKE=yes will bring - gmake into - RUN_DEPENDS, despite that it was not - included explicitly in BUILD_DEPENDS. To - prevent this from happening, immediate expansion assignment - should be used, i.e. expand the value before assigning it - to the variable: + However, such assignment can pollute run-time dependencies + with entries not defined in the port's original BUILD_DEPENDS. + This happens because of &man.make.1;'s lazy evaluation of variable + assignment. Consider a Makefile with + USE_* variables, which + are processed by ports/Mk/bsd.*.mk to augment + initial build dependencies. For example, USE_GMAKE=yes + adds devel/gmake to + BUILD_DEPENDS. To prevent such additional dependencies + from polluting RUN_DEPENDS, take care to assign + with expansion, i.e. expand the value before assigning it to the + variable: RUN_DEPENDS:= ${BUILD_DEPENDS}