From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 23:40:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82B3337B401 for ; Thu, 3 Apr 2003 23:40:48 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE69943F75 for ; Thu, 3 Apr 2003 23:40:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0180.cvx40-bradley.dialup.earthlink.net ([216.244.42.180] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 191LoG-0006sm-00; Thu, 03 Apr 2003 23:40:25 -0800 Message-ID: <3E8D3697.3EC98625@mindspring.com> Date: Thu, 03 Apr 2003 23:39:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20030403212300.GL54604@garage.freebsd.pl> <20030404071346.GN54604@garage.freebsd.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42cdc4570027d3e5fb8dc24ab68662db92601a10902912494350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Marcel Moolenaar Subject: Re: Bug in make(1)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 07:40:48 -0000 Pawel Jakub Dawidek wrote: > On Thu, Apr 03, 2003 at 01:50:59PM -0800, Marcel Moolenaar wrote: > +> Because you told make(1) to by virtue of including bsd.prog.mk > +> > +> OBJS is derived from SRCS by replacing the extension. If SRCS > +> contains foo/bar.c, OBJS will contain foo/bar.o... > > Yes, but take a look on compilation process. When file is compilated > '-o' isn't specified (gcc -c test/tst.c), but when executable file is > produced, gcc looks for tst.o in test directory (gcc -o tst test/tst.o). > And IMHO if gcc want to look for objects somewhere it should put them > there, so: gcc -o test/tst.o -c test/tst.c. Sometimes it is hard to > change. The real problem is that the object directory is often intentionally not the source directory. The libc_r build procedure works this way. You don't want to list source objects by path; you want to use subdir Makefile's, and the constructs that are there to support obtaining sources from alternate directories. You should look at the ".PATH:" directive. For the "test/tst.c" case, probably the correct thing to do is use something like: .PATH: ${.CURDIR}/test ... # source files from test/*; if names collide, you should be # using a library, instead of compiling direct subdir sources SRCS+= tst.c ... .include This will cause tst.o to both be crated, and referenced, from the directory in which the Makefile resides, instead of mixing references to the subdirectory "test". FWIW: I've been annoyed by the behaviour, as well; however... I understand how, if one is using an OBJDIR, that using subdirectories below the directories, without sub-Makefiles to create the objects, could make the build system parallel object directory creation fail. -- Terry