From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 13:17:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E819916A4CF; Fri, 20 Aug 2004 13:17:55 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id B406343D46; Fri, 20 Aug 2004 13:17:54 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7KDHjX518802; Fri, 20 Aug 2004 15:17:46 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7KDHjI84326; Fri, 20 Aug 2004 15:17:45 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7KDHie11431; Fri, 20 Aug 2004 15:17:44 +0200 (MET DST) Date: Fri, 20 Aug 2004 15:17:46 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Ruslan Ermilov In-Reply-To: <20040820123605.GD29568@ip.net.ua> Message-ID: <20040820150410.M585@beagle.kn.op.dlr.de> References: <20040820123605.GD29568@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Oliver Eikemeier Subject: Re: setting CFLAGS in /etc/make.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2004 13:17:56 -0000 On Fri, 20 Aug 2004, Ruslan Ermilov wrote: RE>On Fri, Aug 20, 2004 at 02:08:33PM +0200, Oliver Eikemeier wrote: RE>> I run into this recently with mail/exim. Of course it was possible to RE>> work around this too, but it happened only when certain configuration RE>> options where given *and* CFLAGS was set in /etc/make.conf. There must RE>> be a better way to deal with this. RE>> RE>Facts: RE> RE>1. In FreeBSD, CFLAGS (if not explicitly set, or set in /etc/make.conf) RE> is the global make(1) variable. RE> RE>2. FreeBSD make(1) knows about environment and global variables, and RE> global variables take precedence over environment variables. RE> RE>3. If CFLAGS is not explicitly set in /etc/make.conf, and CFLAGS is RE> set in environment instead, its value becomes a value of the CFLAGS RE> make(1) global variable: RE> RE>: $ cat makefile RE>: FOO+= bar RE>: RE>: all: RE>: @echo global FOO: ${FOO} RE>: @echo env FOO: $${FOO} RE>: $ FOO=foo make RE>: global FOO: foo bar RE>: env FOO: foo RE> RE>So, if you need to change another makefile's idea of the initial value RE>of CFLAGS, you basically have two reliable choices: RE> RE>a) Don't use /etc/make.conf to avoid the possibility of setting RE> CFLAGS in /etc/make.conf. RE> RE>b) Modify this another makefile to add things you want to CFLAGS; RE> the modification may be either hardcoded, or using another RE> macro whose value you can then pass as environment variable. RE> RE>There's no other reliable way, and FreeBSD make(1) doesn't provide RE>you a way to initialize a variable in the global context on the RE>command line or from environment, except for -D which would set it RE>to "1". You can only modify global variables from makefile or RE>from its included sources. RE> RE>P.S. I start to hate command-line variable in make(1). ;) They have their place so you could do make CC=icc without caring what Makefile does try to set CC. You just need to use them for the things they are intended for. The problem with CFLAGS is that it is overloaded to be a variable that should be twiddled by the user, by make (via .mk and make.conf) and by individual makefiles. This is normally (read on other systems) not the case - CFLAGS used to be a variable used by makefiles. I think setting CFLAGS from make.conf is bad. make.conf should probably have a different variable (something like CFLAGS_DEFAULT or whatever) that just gets applied at the places where CFLAGS is used to pass them to a command. This would somewhat (but not entirely) decouple the different CFLAGS uses. Another step would be to have CFLAGS_SYS (or whatever) that gets set in *.mk. So we would end up with ${CC} ${CFLAGS} ${CFLAGS_DEFAULT} ${CFLAGS_SYS} ... and everybody could do with CFLAGS whatever he needs to do. harti