From owner-freebsd-doc@FreeBSD.ORG Thu Nov 30 13:30:27 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8AF016A492 for ; Thu, 30 Nov 2006 13:30:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id D678343CB4 for ; Thu, 30 Nov 2006 13:30:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAUDUOkw072318 for ; Thu, 30 Nov 2006 13:30:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAUDUO4F072316; Thu, 30 Nov 2006 13:30:24 GMT (envelope-from gnats) Resent-Date: Thu, 30 Nov 2006 13:30:24 GMT Resent-Message-Id: <200611301330.kAUDUO4F072316@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ganael LAPLANCHE Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1965D16A407 for ; Thu, 30 Nov 2006 13:27:09 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 002B943CA3 for ; Thu, 30 Nov 2006 13:27:00 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id kAUDR8Wc048126 for ; Thu, 30 Nov 2006 13:27:08 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id kAUDR8xP048125; Thu, 30 Nov 2006 13:27:08 GMT (envelope-from nobody) Message-Id: <200611301327.kAUDR8xP048125@www.freebsd.org> Date: Thu, 30 Nov 2006 13:27:08 GMT From: Ganael LAPLANCHE To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: docs/106065: [Doc update] Auto-detected configure options (follows PR/105868) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 13:30:27 -0000 >Number: 106065 >Category: docs >Synopsis: [Doc update] Auto-detected configure options (follows PR/105868) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Thu Nov 30 13:30:19 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Ganael LAPLANCHE >Release: FreeBSD 6.2-PRERELEASE amd64 >Organization: http://contribs.martymac.com >Environment: System: FreeBSD home.martymac.com 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Sat Oct 21 10:24:44 CEST 2006 root@martymac.com:/usr/src/sys/amd64/compile/MYKERNEL amd64 >Description: Here is a new page for 'Dos and don'ts' describing the problem encountered in PR/105868 related to auto-detections in a configure script. It explains why it is important for a porter to explicitly add --without- or --disable- options when a functionality is disabled. >How-To-Repeat: >Fix: Patch attached with submission follows: --- en_US.ISO8859-1/books/porters-handbook/book.sgml.orig Thu Nov 30 09:36:46 2006 +++ en_US.ISO8859-1/books/porters-handbook/book.sgml Thu Nov 30 10:42:42 2006 @@ -8784,6 +8784,78 @@ them. + + Configure script and feature auto-activation + + + Control your port + + When using a configure script, keep control on what feature is activated + or not. Avoid using auto-detection of libraries that would silently activate + something you wouldn't be aware of. Say, explicitly disable options when you + do not want them activated (do not just activate them when you want them). + + + + Example + + Silently-activated features can bring you in trouble, let's give an example : + + + + I have libxxx installed on my system (not used by any program) + + + + I don't want the application yyy to be built with xxx support so I disable the xxx option in the port's 'make config' or by defining the WITHOUT_XXX option + + + + Unfortunately, the port manages the option by *only* adding a --with-xxx (or --enable-xxx) option to CONFIGURE_ARGS when WITH_XXX is defined (so nothing happens here) + + + + The configure script is run and detects the library. It silently activates the option since our machine *can* run the xxx option + + + + The application is built with the xxx option + + + + + + + The bad things + + Why is it so bad ? + + + + I have a feature I didn't want (that I have explicitly disabled) + + + + I can uninstall libxxx and break my application yyy, since no dependency is recorded in the database + + + + + + + A solution + + So, what can I do ? + + When possible, add (force) the corresponding --disable- or --without- option + for *each* --enable- or --with one you are using in the port's Makefile (if + supported by the configure script). This will ensure that each dependency is + recorded and that the port installs *exactly* the features users want. + + + + + <makevar>WRKDIR</makevar> >Release-Note: >Audit-Trail: >Unformatted: