From MAILER-DAEMON Sun Feb 01 03:35:00 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LTXnA-0006up-2B for mharc-automake@gnu.org; Sun, 01 Feb 2009 03:35:00 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LTXn7-0006sq-Vj for automake@gnu.org; Sun, 01 Feb 2009 03:34:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LTXn5-0006qj-Nh for automake@gnu.org; Sun, 01 Feb 2009 03:34:56 -0500 Received: from [199.232.76.173] (port=53710 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LTXn5-0006qL-I7 for automake@gnu.org; Sun, 01 Feb 2009 03:34:55 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:35841) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LTXn4-00016u-TG for automake@gnu.org; Sun, 01 Feb 2009 03:34:55 -0500 Received: from localhost.localdomain (xdsl-87-78-66-239.netcologne.de [87.78.66.239]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id EB288400045CF; Sun, 1 Feb 2009 09:34:51 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LTXjt-0000ej-Ps; Sun, 01 Feb 2009 09:31:37 +0100 Date: Sun, 1 Feb 2009 09:31:37 +0100 From: Ralf Wildenhues To: =?iso-8859-1?B?QW5kculzIEcu?= Aragoneses Message-ID: <20090201083137.GB22877@ins.uni-bonn.de> Mail-Followup-To: =?iso-8859-1?B?QW5kculzIEcu?= Aragoneses , automake@gnu.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: automake without make? X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 08:34:58 -0000 Hello Andr=E9s, * "Andr=E9s G. Aragoneses" wrote on Sun, Feb 01, 2009 at 02:32:26AM CET: > Can automake be used without having make installed? If yes, in which > kind of scenarios? I'm just thinking that, if there's no scenario, the > automake package in a distro should depend on the make package, right? In addition to Russ' reply, it should be possible to use any make implementation (that roughly conforms to POSIX), so a dependency on, say, GNU make, would be stricter than necessary. For example, Debian also packages BSD make (as pmake) and that does just fine with files generated by automake. Cheers, Ralf From MAILER-DAEMON Sun Feb 01 04:45:37 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LTYtU-0001n4-TL for mharc-automake@gnu.org; Sun, 01 Feb 2009 04:45:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LTYtS-0001mz-8H for automake@gnu.org; Sun, 01 Feb 2009 04:45:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LTYtQ-0001mn-Eb for automake@gnu.org; Sun, 01 Feb 2009 04:45:32 -0500 Received: from [199.232.76.173] (port=34586 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LTYtQ-0001mk-8f for automake@gnu.org; Sun, 01 Feb 2009 04:45:32 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:34074) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LTYtP-00028H-Nu for automake@gnu.org; Sun, 01 Feb 2009 04:45:32 -0500 Received: from localhost.localdomain (xdsl-87-78-66-239.netcologne.de [87.78.66.239]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id CACEA4000486A; Sun, 1 Feb 2009 10:45:30 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LTYtO-0000pZ-Fp; Sun, 01 Feb 2009 10:45:30 +0100 Date: Sun, 1 Feb 2009 10:45:30 +0100 From: Ralf Wildenhues To: Peter Rosin Message-ID: <20090201094529.GI22877@ins.uni-bonn.de> Mail-Followup-To: Peter Rosin , automake@gnu.org References: <4977803E.8040908@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4977803E.8040908@lysator.liu.se> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: cl -c -o trouble in libtool am-subdir.at X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 09:45:35 -0000 Hi Peter, * Peter Rosin wrote on Wed, Jan 21, 2009 at 09:06:22PM CET: > For some years now, I've been working on and off on adding MSVC > support w/o wrapper scripts to libtool (see the pr-msvc-support > branch in libtool git) and have run into an issue that has been > brought up here before. > > http://lists.gnu.org/archive/html/automake/2007-06/msg00083.html > > I was trying to fix the am-subdir.at test in the libtool testsuite. > That test uses C++ and compiles in subdirs, so it's really no big > surprise that MSVC is in trouble there. > > In short, MSVC w/o wrapper needs AM_PROG_CXX_C_O for that test to work > (a few other minor tweeks might also be needed, methinks...). > > Can such a macro be added to automake, please? I'm thinking that this issue could be fixed more efficiently by parametrizing '-o '. IIRC then cl accepts /OUT:FILE or -out:FILE (the latter is better to avoid MSYS path translation) or so, right? Then the alternate settings minuso = -out: minuso_CXX = -out: minuso = -o '' minuso_CXX = -o '' should work (I don't know of a good way to get a trailing space through to make without such a quoting helper construct). Upsides of this approach: - avoid another wrapper script for MSVC, thus faster. (Possible) downsides of this approach: - works only for MSVC, not for old C and C++ compilers (the only C++ one we know of is the SCO one), and old Fortran compilers, - users' Makefile.am scripts may need adjustment (when users have added compile rules) - the non-MSVC rules will look uglier. - On some systems, GNU make may start forking a shell for executing compile commands where it didn't do so before. For example, the current construct_command_argv_internal heuristic would make the appearance of single quotes start a shell for DOS (but not for unixy systems). I'm not sure whether this is worth the hassle. If you have better ideas (e.g., to avoid some of the downsides), I'm all ears. All other things being equal, the GNU stance of not pessimizing code in order to support w32 better would of course speak against this, too. Otherwise, yes, I can dig up those AM_PROG_*_C_O patches. Their downside for non-MSVC is another configure test, and another macro for users to put in configure.ac. Cheers, Ralf From MAILER-DAEMON Mon Feb 02 06:10:09 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LTwgr-0003ZA-83 for mharc-automake@gnu.org; Mon, 02 Feb 2009 06:10:09 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LTwgo-0003Ye-9r for automake@gnu.org; Mon, 02 Feb 2009 06:10:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LTwgm-0003YR-LP for automake@gnu.org; Mon, 02 Feb 2009 06:10:05 -0500 Received: from [199.232.76.173] (port=43505 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LTwgm-0003YO-IM for automake@gnu.org; Mon, 02 Feb 2009 06:10:04 -0500 Received: from main.gmane.org ([80.91.229.2]:60281 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LTwgm-0007pi-6D for automake@gnu.org; Mon, 02 Feb 2009 06:10:04 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LTwgk-0000Zt-VP for automake@gnu.org; Mon, 02 Feb 2009 11:10:02 +0000 Received: from 213.91.219.2 ([213.91.219.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Feb 2009 11:10:02 +0000 Received: from yavor by 213.91.219.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Feb 2009 11:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: automake@gnu.org From: Yavor Doganov Date: Mon, 2 Feb 2009 11:06:01 +0000 (UTC) Organization: The GNU Emacs Church (Bulgarian eparchy) Lines: 5 Message-ID: References: <20090201083137.GB22877@ins.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 213.91.219.2 X-Operating-System: GNU/Linux User-Agent: Pan/0.132 (Waxed in Black) Sender: news X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: automake without make? X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 11:10:06 -0000 В Sun, 01 Feb 2009 09:31:37 +0100, Ralf Wildenhues написа: > For example, Debian also packages BSD make (as pmake) That's NetBSD make, I think. The FreeBSD version is in the freebsd-buildutils package (the binary is /usr/bin/freebsd-make). From MAILER-DAEMON Tue Feb 03 10:08:05 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LUMse-0004ci-VU for mharc-automake@gnu.org; Tue, 03 Feb 2009 10:08:05 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUDbr-00015E-41 for automake@gnu.org; Tue, 03 Feb 2009 00:14:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUDbp-00014e-W5 for automake@gnu.org; Tue, 03 Feb 2009 00:14:06 -0500 Received: from [199.232.76.173] (port=39177 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUDbp-00014a-MN for automake@gnu.org; Tue, 03 Feb 2009 00:14:05 -0500 Received: from dsl254-083-208.nyc1.dsl.speakeasy.net ([216.254.83.208]:52310 helo=oak.schemamania.org) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUDbp-0000Wm-DF for automake@gnu.org; Tue, 03 Feb 2009 00:14:05 -0500 Received: by oak.schemamania.org (Postfix, from userid 1012) id 2137650D4E; Mon, 2 Feb 2009 23:50:55 -0500 (EST) Received: from oak.schemamania.org (localhost [127.0.0.1]) by oak.schemamania.org (Postfix) with SMTP id CBA5950C28 for ; Mon, 2 Feb 2009 23:50:54 -0500 (EST) Date: Mon, 2 Feb 2009 23:50:54 -0500 From: "James K. Lowden" To: automake@gnu.org Message-Id: <20090202235054.5221d827.jklowden@freetds.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.92.8 X-detected-operating-system: by monty-python.gnu.org: NetBSD 1.6Z or 2.0 (DF) X-Greylist: delayed 1370 seconds by postgrey-1.27 at monty-python; Tue, 03 Feb 2009 00:13:45 EST X-Mailman-Approved-At: Tue, 03 Feb 2009 10:08:03 -0500 Subject: copy check_SCRIPTS to build directory X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 05:14:07 -0000 Hello, I have 25 unit tests that each process an SQL script: t0001 < t0001.sql t0002 < t0002.sql etc. (Yeah, we planned for a lot of tests!) I like to use a separate build directory, per the Autobook's advice. How do I tell automake to copy the scripts to the build directory? Since there is no requirement to modify the script, I didn't want to bother with a makefile rule that converts, say, t0001.sql.in to t0001.sql. I have tried: SQL_DIST = t0001.sql t0002.sql ... check_SCRIPTS = $(SQL_DIST) $(SQL_DIST): ln -s $(srcdir)/$@ . but no joy. Many thanks for any advice. --jkl From MAILER-DAEMON Tue Feb 03 18:38:12 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LUUqK-0008RB-CI for mharc-automake@gnu.org; Tue, 03 Feb 2009 18:38:12 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUUqI-0008Qu-0r for automake@gnu.org; Tue, 03 Feb 2009 18:38:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUUqF-0008Qi-Hf for automake@gnu.org; Tue, 03 Feb 2009 18:38:08 -0500 Received: from [199.232.76.173] (port=50568 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUUqF-0008Qf-DC for automake@gnu.org; Tue, 03 Feb 2009 18:38:07 -0500 Received: from mail-qy0-f17.google.com ([209.85.221.17]:50882) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUUqE-0001rJ-Vc for automake@gnu.org; Tue, 03 Feb 2009 18:38:07 -0500 Received: by qyk10 with SMTP id 10so3177188qyk.18 for ; Tue, 03 Feb 2009 15:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mail-followup-to:mime-version:content-type :content-disposition:user-agent; bh=6JMWlS6/ZhmujTK+uc7k0GND8E3oy1OQfhxAEJwlmss=; b=tOYLu8ZoSwDixb4HDjy825ybFDm6/jQLLsn5QaSBe6m49RaX0RoR6U0RxSS/9KvW6e cGrmVOwUj4LNnyAJKdCtWDRP/B4TJnjY+gq6U22u3Qi/9yZO2EDFuTJlonzAngOZL5o5 lI+JhbxR5nbwrNxOBzVWPHcYFJ8ZKrYpMifvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; b=AGrPENI48FdXcyDanjor9EWV5TCUggUcUM1eit4B798IdKJSgemkc3hkZMgmB6ikPD PUsCmEX0sniTt1wSt7HHLpJGLEL41AK9IdljkW9nRVMsWM8r+kyEkXyLcQ8uKBS5/rID qjoLKn+MxvDTTEdgjWYpDIMdetclwnNioJF2k= Received: by 10.214.114.17 with SMTP id m17mr3303118qac.21.1233704285095; Tue, 03 Feb 2009 15:38:05 -0800 (PST) Received: from linux.vnet (pool-71-185-49-127.phlapa.fios.verizon.net [71.185.49.127]) by mx.google.com with ESMTPS id 6sm1088074ywn.47.2009.02.03.15.38.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Feb 2009 15:38:04 -0800 (PST) Date: Tue, 3 Feb 2009 18:38:01 -0500 From: Allan Caffee To: Allan Caffee , automake@gnu.org Message-ID: <20090203233801.GA6308@linux.vnet> Mail-Followup-To: automake@gnu.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Subject: AX_ADD_AM_MACRO creates circular dependencies X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 23:38:10 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline First of all I wasn't really sure where to start this thread so if this isn't the appropriate place I apologize. I've noticed that a handful of the packages in the Autoconf archives use the macros AX_ADD_AM_MACRO and AX_ADD_RECURSIVE_AM_MACRO. These macros add targets and variable assignments to a generated file $(top_srcdir)/aminclude.am. Users are then intended to add a line like include $(top_srcdir)/aminclude.am to whichever Makefile.am needs the provided functionality. The problem with this is that Makefile.in now depends on aminclude.am. And aminclude.am is created by configure. And in turn configure cannot be run (successfully) without Makefile.in. So in order to even get a useable build system the developer has to touch aminclude.am. This circular dependency is inconvenient for developers but what's even worse is that any user who tries to compile this project from a source tarball must now have Automake installed. Why? Because aminclude.am is generated at configure-time and included Automake files are inserted into the Makefile.in when Automake runs. This means that (even if the actual contents of aminclude.am are identical to those in the tarball) running ./configure && make on a source will (detecting the change in a dependency of Makfile.am) automatically rerun Automake. One possible solution to this would be to have the macros responsible for generating Automake code instead create the file when Autoconf is run via something like m4_esyscmd([printf "$2" >> $1]) This should guarantee that the files exist and have the right content before Automake begins to run. I'm including a simple example that demonstrates this issue. Thoughts? Allan --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="configure.ac" # -*- Autoconf -*- AC_PREREQ(2.59) AC_INIT([hello], [0.0.0]) AC_CONFIG_SRCDIR([hello.c]) AM_INIT_AUTOMAKE([-Wall -Werror foreign]) AC_PROG_CC AX_ADD_AM_MACRO([ foo: @echo This is my foo target ]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT --gBBFr7Ir9EOA20Yy Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="hello.c" #include int main (int argc, char * argv[]) { printf ("Hello world!\n"); return 0; } --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Makefile.am" include $(top_srcdir)/aminclude.am bin_PROGRAMS = hello hello_SOURCES = hello.c --gBBFr7Ir9EOA20Yy-- From MAILER-DAEMON Wed Feb 04 04:33:48 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LUe8h-0007ft-Sm for mharc-automake@gnu.org; Wed, 04 Feb 2009 04:33:47 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUe8f-0007fY-L3 for automake@gnu.org; Wed, 04 Feb 2009 04:33:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUe8d-0007fL-DV for automake@gnu.org; Wed, 04 Feb 2009 04:33:44 -0500 Received: from [199.232.76.173] (port=38107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUe8d-0007fI-5m for automake@gnu.org; Wed, 04 Feb 2009 04:33:43 -0500 Received: from smtp6-g21.free.fr ([212.27.42.6]:58336) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUe8c-0000gK-F5 for automake@gnu.org; Wed, 04 Feb 2009 04:33:43 -0500 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5DB04E08119; Wed, 4 Feb 2009 10:33:37 +0100 (CET) Received: from eana.kheb.homelinux.org (unknown [82.224.152.139]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3EA3BE081C1; Wed, 4 Feb 2009 10:33:35 +0100 (CET) Date: Wed, 4 Feb 2009 10:33:34 +0100 From: Michel Briand To: Ralf Wildenhues , automake@gnu.org Message-ID: <20090204103334.36472a70@eana.kheb.homelinux.org> In-Reply-To: <20090203180651.GA6565@ins.uni-bonn.de> References: <20090203180911.4b972f9d@eana.kheb.homelinux.org> <20090203180651.GA6565@ins.uni-bonn.de> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: Where to generate .lo files ? X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 09:33:45 -0000 Ralf Wildenhues - Tue, 3 Feb 2009 19:06:52 +0100 >Hello Michel, > >* Michel Briand wrote on Tue, Feb 03, 2009 at 06:09:11PM CET: >>=20 >> I wonder if it's possible to tell libtool to generate .lo file >> elsewhere than in source directory (where Makefile resides). > >Yes: > libtool --mode=3Dcompile $CC -o some/where/foo.lo -c else/where/foo.c > >If you're using Automake, then you're probably looking for the Automake >option subdir-objects, which causes objects to put in directories along >the subdir of the source files provided. > Hello, yes, I'm using automake. I put the sub-objects into my AM_INIT_AUTOMAKE. It works like you explained. Thanks. But why does it's not the default behavior ? I wanted to have my source directory cleaner: all .o files, plus .lo files, plus .Plo.... This makes directories unreadable.... Furthermore I noted that .o files are twice for one source file: $ find . -name "main.*" -ls 4964623 4 -rw-r--r-- 1 michel users 266 f=E9v 4 10:22 ./mai= n.lo 4440187 8 -rw-r--r-- 1 michel users 5268 f=E9v 4 10:22 ./.li= bs/main.o 4394955 8 -rw-r--r-- 1 michel users 4544 f=E9v 4 10:22 ./.de= ps/main.Plo 4964367 8 -rw-r--r-- 1 michel users 5000 f=E9v 4 10:22 ./mai= n.o 10371366 4 -r--r--r-- 1 michel users 804 d=E9c 2 18:41 ./ma= in.c I do not really understand here. Two main.o ! Cheers, Michel From MAILER-DAEMON Wed Feb 04 05:00:41 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LUeYi-0006MX-Un for mharc-automake@gnu.org; Wed, 04 Feb 2009 05:00:40 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUeYh-0006MS-RF for automake@gnu.org; Wed, 04 Feb 2009 05:00:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUeYb-0006MF-3x for automake@gnu.org; Wed, 04 Feb 2009 05:00:37 -0500 Received: from [199.232.76.173] (port=51107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUeYb-0006MC-0J for automake@gnu.org; Wed, 04 Feb 2009 05:00:33 -0500 Received: from sovereign.computergmbh.de ([85.214.69.204]:51056) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LUeYa-0002zF-Bk for automake@gnu.org; Wed, 04 Feb 2009 05:00:32 -0500 Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 59515E6001; Wed, 4 Feb 2009 11:00:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 584B042514AE; Wed, 4 Feb 2009 11:00:27 +0100 (CET) Date: Wed, 4 Feb 2009 11:00:27 +0100 (CET) From: Jan Engelhardt Sender: jengelh@sovereign.computergmbh.de To: Michel Briand In-Reply-To: <20090204103334.36472a70@eana.kheb.homelinux.org> Message-ID: References: <20090203180911.4b972f9d@eana.kheb.homelinux.org> <20090203180651.GA6565@ins.uni-bonn.de> <20090204103334.36472a70@eana.kheb.homelinux.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Where to generate .lo files ? X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 10:00:40 -0000 On Wednesday 2009-02-04 10:33, Michel Briand wrote: > >Furthermore I noted that .o files are twice for one source file: > >$ find . -name "main.*" -ls >4964623 4 -rw-r--r-- 1 michel users 266 f=C3=A9v 4 10:22= ./main.lo >4440187 8 -rw-r--r-- 1 michel users 5268 f=C3=A9v 4 10:22= ./.libs/main.o >4394955 8 -rw-r--r-- 1 michel users 4544 f=C3=A9v 4 10:22= ./.deps/main.Plo >4964367 8 -rw-r--r-- 1 michel users 5000 f=C3=A9v 4 10:22= ./main.o >10371366 4 -r--r--r-- 1 michel users 804 d=C3=A9c 2 18:4= 1 ./main.c > >I do not really understand here. Two main.o ! One without, and one with -fPIC. From MAILER-DAEMON Wed Feb 04 16:21:08 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LUpBE-0007fW-A5 for mharc-automake@gnu.org; Wed, 04 Feb 2009 16:21:08 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUp5j-0005kG-2m for automake@gnu.org; Wed, 04 Feb 2009 16:15:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUp5h-0005j7-DN for automake@gnu.org; Wed, 04 Feb 2009 16:15:26 -0500 Received: from [199.232.76.173] (port=55607 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUp5h-0005j1-A9 for automake@gnu.org; Wed, 04 Feb 2009 16:15:25 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:60142) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUp5h-0002YP-10 for automake@gnu.org; Wed, 04 Feb 2009 16:15:25 -0500 Received: from localhost.localdomain (xdsl-87-78-91-178.netcologne.de [87.78.91.178]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 25E6C400042C8; Wed, 4 Feb 2009 22:15:24 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LUp5f-0003PS-OY; Wed, 04 Feb 2009 22:15:23 +0100 Date: Wed, 4 Feb 2009 22:15:23 +0100 From: Ralf Wildenhues To: Michel Briand Message-ID: <20090204211522.GD12894@ins.uni-bonn.de> Mail-Followup-To: Michel Briand , automake@gnu.org References: <20090203180911.4b972f9d@eana.kheb.homelinux.org> <20090203180651.GA6565@ins.uni-bonn.de> <20090204103334.36472a70@eana.kheb.homelinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090204103334.36472a70@eana.kheb.homelinux.org> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Where to generate .lo files ? X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 21:15:27 -0000 * Michel Briand wrote on Wed, Feb 04, 2009 at 10:33:34AM CET: > Ralf Wildenhues - Tue, 3 Feb 2009 19:06:52 +0100 > > > >If you're using Automake, then you're probably looking for the Automake > >option subdir-objects, which causes objects to put in directories along > >the subdir of the source files provided. > I put the sub-objects into my AM_INIT_AUTOMAKE. It works like you > explained. Thanks. But why does it's not the default behavior ? Oh, the reason for that is probably portability issues in tools from years ago. I can only speculate, but old make implementations probably had less than spectacular support for the VPATH feature with files that have directory components. Solaris 2.6 make for example is quite broken that way. Another issue is that more compilers existed which did not support being passed both -c and -o, thus having the object file placed in the current directory was in a sense "more natural". > Furthermore I noted that .o files are twice for one source file: Well, that is "normal" for objects that are being put into libraries: one object is compiled with position-independent code, one without. Jan already noted this. It shouldn't happen for objects that only end up in programs though. For example, with this: bin_PROGRAMS = foo lib_LTLIBRARIES = libbar.la foo_SOURCES = foo.c libbar_la_SOURCES = bar.c only bar.c will be compiled twice, but not foo.c. With convenience archives, objects are created twice because they may end up being incorporated into libraries later. Hope that helps. Cheers, Ralf From MAILER-DAEMON Tue Feb 10 05:20:09 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LWpir-0000bV-6k for mharc-automake@gnu.org; Tue, 10 Feb 2009 05:20:09 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWpio-0000ZL-Eh for automake@gnu.org; Tue, 10 Feb 2009 05:20:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWpik-0000Vv-R1 for automake@gnu.org; Tue, 10 Feb 2009 05:20:05 -0500 Received: from [199.232.76.173] (port=53235 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWpik-0000Vj-MG for automake@gnu.org; Tue, 10 Feb 2009 05:20:02 -0500 Received: from smtp2-g21.free.fr ([212.27.42.2]:55398) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LWpik-0007yT-3o for automake@gnu.org; Tue, 10 Feb 2009 05:20:02 -0500 Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 2F55F4B0156 for ; Tue, 10 Feb 2009 11:19:54 +0100 (CET) Received: from eana.kheb.homelinux.org (unknown [82.224.152.139]) by smtp2-g21.free.fr (Postfix) with ESMTP id 1A55B4B01F8 for ; Tue, 10 Feb 2009 11:19:52 +0100 (CET) Date: Tue, 10 Feb 2009 11:19:51 +0100 From: Michel Briand To: automake@gnu.org Message-ID: <20090210111951.2976c1b8@eana.kheb.homelinux.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: make dist and data package X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 10:20:06 -0000 Hello all, I'm working on a project that release code/library but also a large amount of data. I wonder if it's possible to create 2 packages with make dist. One for the software, one for the data directory ? Cheers, Michel -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile. From MAILER-DAEMON Tue Feb 10 13:07:16 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LWx0u-0000QZ-7h for mharc-automake@gnu.org; Tue, 10 Feb 2009 13:07:16 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWx0s-0000Pq-Gh for automake@gnu.org; Tue, 10 Feb 2009 13:07:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWx0p-0000Ok-Bf for automake@gnu.org; Tue, 10 Feb 2009 13:07:13 -0500 Received: from [199.232.76.173] (port=59291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWx0p-0000Ob-5m for automake@gnu.org; Tue, 10 Feb 2009 13:07:11 -0500 Received: from smtpfb1-g21.free.fr ([212.27.42.9]:56448) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LWx0o-0002Le-4i for automake@gnu.org; Tue, 10 Feb 2009 13:07:10 -0500 Received: from wmproxy2-g27.free.fr (wmproxy2-g27.free.fr [212.27.42.92]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 6A2B33031C for ; Tue, 10 Feb 2009 19:06:00 +0100 (CET) Received: from zimbra20-e3.priv.proxad.net (zimbra20-e3.priv.proxad.net [172.20.243.170]) by wmproxy2-g27.free.fr (Postfix) with ESMTP id 7AA58A490 for ; Tue, 10 Feb 2009 19:05:59 +0100 (CET) Date: Tue, 10 Feb 2009 19:06:01 +0100 (CET) From: dagecko@free.fr To: automake@gnu.org Message-ID: <1671216860.725911234289161908.JavaMail.root@zimbra20-e3.priv.proxad.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.243.42] X-Mailer: Zimbra 5.0.11_GA_2627.UBUNTU8_64 (ZimbraWebClient - [unknown] (Linux)/5.0.11_GA_2627.UBUNTU8_64) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: automake and dist data X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:07:14 -0000 Hello, I hope someone here will be able to help me. I'm developping a middle-scale library that uses autoconf and automake. This library comes along with some demo and test programs. Those demo and test programs now require some input files in order to run. Those input files also have to be distributed with the package. I actually tried to put those input data files into the header directory and I also wondered if I could put them into the share subdirectory. The problem I'm facing is this one: The test programs will have to read those data, but I actually can't know where those input data are stored (it is top_srcdir/include) but it is somewhat impossible from what I know to give that directory to C/C++ file functions. Of course, I can code that in the hard way. But that will work as long as the project is not installed. But once installed (on any uknown machine), I really can't know where to find those input files. If they are installed in the include subdirectory, then I can have a look at /usr/include, or it might be /usr/local/include, or whatever directory a final user would have put to configure. It is the same thing if I put those data in the share subdirectory. Does anyone has an advice, a hint, or a solution for me ? Thanks From MAILER-DAEMON Tue Feb 10 14:58:53 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LWykv-0006vS-6Y for mharc-automake@gnu.org; Tue, 10 Feb 2009 14:58:53 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWykt-0006uB-Vw for automake@gnu.org; Tue, 10 Feb 2009 14:58:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWyks-0006t5-7S for automake@gnu.org; Tue, 10 Feb 2009 14:58:50 -0500 Received: from [199.232.76.173] (port=33389 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWyks-0006sv-2M for automake@gnu.org; Tue, 10 Feb 2009 14:58:50 -0500 Received: from mail-bw0-f160.google.com ([209.85.218.160]:35937) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LWykr-0000Nc-GH for automake@gnu.org; Tue, 10 Feb 2009 14:58:49 -0500 Received: by bwz4 with SMTP id 4so23262bwz.18 for ; Tue, 10 Feb 2009 11:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=cVTn5cN0AKJcASPTbHOkc4wLEw2vYIzBCbmr+BACF/o=; b=sD7H4MnHCfMvckh2NWKYu7rwttvTYyLD+gHiTSaRj5MqzTPlJO/efWFH9yyYT2sSJ3 gs3CkaIyt2EqQs69Zactp/NUZOJDzpF+OTNAWmCtrZKbbE00rxfh8uKbSMoUCqgYreNa u2M/zFcBCbz6+zA6eOLqJHxTJ2d0Grw8StRYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=llDonExfzmLey8vn/SXHan/szY6eHn1vpQAzcw7L057mAsh8GLzVY36c+Ub8kJ9Nio TF7GNySfcGmr/8VsQPcmpL6H0QnruW+UkTktuWVHMT2i67xeNVn7WCAJRbPgJs3FrIfT VWefY5aYkkiHtWajvQ5ZuMi+NaEc4J4u61dzw= Received: by 10.223.113.194 with SMTP id b2mr1921814faq.80.1234295596049; Tue, 10 Feb 2009 11:53:16 -0800 (PST) Received: from ?192.168.0.107? (klient-catv-iv-293.selfnet.cz [213.211.57.37]) by mx.google.com with ESMTPS id 7sm55250fxm.69.2009.02.10.11.53.14 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Feb 2009 11:53:15 -0800 (PST) From: =?UTF-8?Q?Mat=C4=9Bj_T=C3=BD=C4=8D?= To: dagecko@free.fr In-Reply-To: <1671216860.725911234289161908.JavaMail.root@zimbra20-e3.priv.proxad.net> References: <1671216860.725911234289161908.JavaMail.root@zimbra20-e3.priv.proxad.net> Content-Type: text/plain Date: Tue, 10 Feb 2009 20:53:05 +0100 Message-Id: <1234295585.2890.19.camel@matej-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: automake@gnu.org Subject: Re: automake and dist data X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:58:52 -0000 What I do (not sure whether it is correct) is that I define a variable in configure.ac: AC_ARG_WITH([datadir], [AS_HELP_STRING([--with-datadir=path-to-your-foo-datafiles], [Normally you don't have to use this, but it is handy when you want to use foo without installing it or if you want to use already installed data. In the first case, use for instance --with-datadir=`pwd`/data (if it makes sense) ])], [DATADIR_NAME="$with_datadir"], [DATADIR_NAME='$(datadir)/'foo]) AC_SUBST([DATADIR_NAME]) I provide a possibility for the user to specify the content of the variable DATADIR_NAME variable like that, but the default is '$(datadir)/'foo Then I have this in my Makefile.am: AM_CPPFLAGS = -D'DATADIR="@DATADIR_NAME@"' Then the DATADIR macro in your C files are substituted by the variable expanded by automake - for instance '$(datadir)/'foo becomes /usr/share/foo. I think that you should save it to some string inside your program rather than getting deeply involved with the preprocessor. Hope it helps Matej On Tue, 2009-02-10 at 19:06 +0100, dagecko@free.fr wrote: > Hello, > > I hope someone here will be able to help me. > > I'm developping a middle-scale library that uses autoconf and automake. This library comes > along with some demo and test programs. Those demo and test programs now require some > input files in order to run. Those input files also have to be distributed with the > package. I actually tried to put those input data files into the header directory and > I also wondered if I could put them into the share subdirectory. > > The problem I'm facing is this one: > > The test programs will have to read those data, but I actually can't know where those > input data are stored (it is top_srcdir/include) but it is somewhat impossible from > what I know to give that directory to C/C++ file functions. > Of course, I can code that in the hard way. But that will work as long as the project > is not installed. But once installed (on any uknown machine), I really can't know > where to find those input files. If they are installed in the include subdirectory, > then I can have a look at /usr/include, or it might be /usr/local/include, or > whatever directory a final user would have put to configure. It is the same thing if > I put those data in the share subdirectory. > > Does anyone has an advice, a hint, or a solution for me ? > > Thanks > > From MAILER-DAEMON Wed Feb 11 02:00:16 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LX94y-0004Tr-Bs for mharc-automake@gnu.org; Wed, 11 Feb 2009 02:00:16 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LX5KA-0001DK-Sz for automake@gnu.org; Tue, 10 Feb 2009 21:59:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LX5K6-0001D4-Fl for automake@gnu.org; Tue, 10 Feb 2009 21:59:41 -0500 Received: from [199.232.76.173] (port=50914 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LX5K6-0001D1-Au for automake@gnu.org; Tue, 10 Feb 2009 21:59:38 -0500 Received: from wf-out-1314.google.com ([209.85.200.175]:28709) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LX5K5-0007pb-Tk for automake@gnu.org; Tue, 10 Feb 2009 21:59:38 -0500 Received: by wf-out-1314.google.com with SMTP id 28so128727wfc.24 for ; Tue, 10 Feb 2009 18:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=i6iT/86/pzvGigR8i6LgDmBX4CzU1BHBhjLtn7Lllwc=; b=kkX8wtR2fgVIOERPkhbZpNpFgiV7yTmDnjibO56dcYS+sK4rNaxXeOCbgrgzm+WvRe hyP1ai2lyETcGA2oYjdif4j8SGopwWRoa/3gVhg9nA/97Zsv+Oxv+NgRoEw2Iz86sQS3 49xQ5xPKH5c7FLMQDglpyBJ2u8kfgOLPU3qVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=QVeIqszlb9eHBfQyUCLF1PPwFMlXEcgYvIfP6LhBcWQxy8lf3IimQ4PUUUsdwsEEiC CiDEstHuGkzDWXLnQh9YS/ps3/DC+X5UzKseFGM77fW7lxPkzsVQaby525L4ihzcaNcM KBeDhVPcTk01TalRrLJ8i2wtVOo4qojJvMtq0= MIME-Version: 1.0 Received: by 10.140.132.3 with SMTP id f3mr5100811rvd.21.1234321176413; Tue, 10 Feb 2009 18:59:36 -0800 (PST) Date: Tue, 10 Feb 2009 20:59:36 -0600 Message-ID: <4a00655d0902101859q454ae142i56d8fab0c857fa41@mail.gmail.com> From: Rhys Ulerich To: Automake Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Wed, 11 Feb 2009 02:00:14 -0500 Subject: Expressing non-source dependency for a VPATH build X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 02:59:43 -0000 Hi all, I've got an autotooled project which I can successfully configure/build using something like ../project/configure && make. Is there some way to express a non-source dependency so that it gets "picked up" in a VPATH build? Maybe symlinked? Specifically, I've got a log4cxx.properties file used by my 'make check' tests. If I run 'make check' in a non-VPATH build the log4cxx.properties file is present and my tests output correctly. However, when I run 'make check' in a VPATH build my tests cannot find log4cxx.properties (its in the source tree, not the build tree) and they don't operate the way I'd like. Any help appreciated, Rhys From MAILER-DAEMON Wed Feb 11 02:05:33 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LX9A5-0006B7-Pn for mharc-automake@gnu.org; Wed, 11 Feb 2009 02:05:33 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LX9A4-0006B0-IF for automake@gnu.org; Wed, 11 Feb 2009 02:05:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LX9A3-0006Ah-Ml for automake@gnu.org; Wed, 11 Feb 2009 02:05:32 -0500 Received: from [199.232.76.173] (port=59930 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LX9A3-0006Ae-Ja for automake@gnu.org; Wed, 11 Feb 2009 02:05:31 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:43955) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LX9A3-0004Ul-6h for automake@gnu.org; Wed, 11 Feb 2009 02:05:31 -0500 Received: from localhost.localdomain (xdsl-87-78-88-59.netcologne.de [87.78.88.59]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 3E2F4400024EB; Wed, 11 Feb 2009 08:05:27 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LX99y-0001J3-O7; Wed, 11 Feb 2009 08:05:26 +0100 Date: Wed, 11 Feb 2009 08:05:26 +0100 From: Ralf Wildenhues To: Rhys Ulerich Message-ID: <20090211070526.GA3414@ins.uni-bonn.de> Mail-Followup-To: Rhys Ulerich , Automake Mailing List References: <4a00655d0902101859q454ae142i56d8fab0c857fa41@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a00655d0902101859q454ae142i56d8fab0c857fa41@mail.gmail.com> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Automake Mailing List Subject: Re: Expressing non-source dependency for a VPATH build X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 07:05:32 -0000 Hello Rhys, * Rhys Ulerich wrote on Wed, Feb 11, 2009 at 03:59:36AM CET: > > I've got an autotooled project which I can successfully > configure/build using something like ../project/configure && make. Is > there some way to express a non-source dependency so that it gets > "picked up" in a VPATH build? Maybe symlinked? Yes, you can add prerequisites to the all-local target. You can write rules for these prerequisites the same way you would write rules for them in a Makefile. > Specifically, I've got a log4cxx.properties file used by my 'make > check' tests. If I run 'make check' in a non-VPATH build the > log4cxx.properties file is present and my tests output correctly. > However, when I run 'make check' in a VPATH build my tests cannot find > log4cxx.properties (its in the source tree, not the build tree) and > they don't operate the way I'd like. Well, it depends on your specific setup whether symlinking/copying the file to the build tree is preferable, or using $(srcdir) appropriately elsewhere. If you decide to symlink/copy, you can use $(LN_S) (put AC_PROG_LN_S in configure.ac). In order to have a deterministic rule, input and output file should have different names (e.g., foo.in -> foo) or not be identifiable by VPATH. Hope that helps. Cheers, Ralf From MAILER-DAEMON Wed Feb 11 12:43:45 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LXJ7h-0003bU-1S for mharc-automake@gnu.org; Wed, 11 Feb 2009 12:43:45 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXJ7g-0003an-1P for automake@gnu.org; Wed, 11 Feb 2009 12:43:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXJ7e-0003Z2-Jk for automake@gnu.org; Wed, 11 Feb 2009 12:43:43 -0500 Received: from [199.232.76.173] (port=49329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXJ7e-0003Ys-C9 for automake@gnu.org; Wed, 11 Feb 2009 12:43:42 -0500 Received: from rv-out-0708.google.com ([209.85.198.249]:25319) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXJ7d-00053V-JE for automake@gnu.org; Wed, 11 Feb 2009 12:43:41 -0500 Received: by rv-out-0708.google.com with SMTP id f25so35601rvb.6 for ; Wed, 11 Feb 2009 09:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=YN46musjUDtHjirg7SfHB9F/4953HK5zEsLgwLiQqpE=; b=IVM4h37W+pMZd4s6XYdynqKJC7/ROvj2hi+dU88yh4MHOMxOW5g1PpK7I9kfhrFpHO ndqKfstOxsK7CYpnuv6MPJDzdJZBfmxe6b31HLwJiXjT2VnQO6Qym78ghEFsRh2wL1tQ mArKNSTIO75y3JKfIXwqIzhUQ2zzptHeWWQ1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=s+TzbGewCF1ibDVdUgNHJ9q6OxS3EYscRLounNwoOVckZFluStLMNl+LHZwzA2pegT 0C3UuG2nyPli9JVlHHwXq+ETSTy6BREbCDTY36aHuBC879xmlEMib3oER2w5i3rJdUpT IeHWGaIGNpgBigvDZak8JwwkRqOurUGOQTNaU= MIME-Version: 1.0 Received: by 10.140.203.9 with SMTP id a9mr5664722rvg.279.1234374220855; Wed, 11 Feb 2009 09:43:40 -0800 (PST) In-Reply-To: <20090211070526.GA3414@ins.uni-bonn.de> References: <4a00655d0902101859q454ae142i56d8fab0c857fa41@mail.gmail.com> <20090211070526.GA3414@ins.uni-bonn.de> Date: Wed, 11 Feb 2009 11:43:40 -0600 Message-ID: <4a00655d0902110943y53dbf380u799efe2bf42e893c@mail.gmail.com> From: Rhys Ulerich To: Automake Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Expressing non-source dependency for a VPATH build X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:43:44 -0000 That worked. I also ran across AC_CONFIG_LINKS which seems to be another option. Thanks Ralf, Rhys On Wed, Feb 11, 2009 at 1:05 AM, Ralf Wildenhues wrote: > Hello Rhys, > > * Rhys Ulerich wrote on Wed, Feb 11, 2009 at 03:59:36AM CET: >> >> I've got an autotooled project which I can successfully >> configure/build using something like ../project/configure && make. Is >> there some way to express a non-source dependency so that it gets >> "picked up" in a VPATH build? Maybe symlinked? > > Yes, you can add prerequisites to the all-local target. You can write > rules for these prerequisites the same way you would write rules for > them in a Makefile. > >> Specifically, I've got a log4cxx.properties file used by my 'make >> check' tests. If I run 'make check' in a non-VPATH build the >> log4cxx.properties file is present and my tests output correctly. >> However, when I run 'make check' in a VPATH build my tests cannot find >> log4cxx.properties (its in the source tree, not the build tree) and >> they don't operate the way I'd like. > > Well, it depends on your specific setup whether symlinking/copying the > file to the build tree is preferable, or using $(srcdir) appropriately > elsewhere. > > If you decide to symlink/copy, you can use $(LN_S) (put AC_PROG_LN_S in > configure.ac). In order to have a deterministic rule, input and output > file should have different names (e.g., foo.in -> foo) or not be > identifiable by VPATH. > > Hope that helps. > > Cheers, > Ralf > From MAILER-DAEMON Thu Feb 12 14:24:51 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LXhB5-0003oY-8R for mharc-automake@gnu.org; Thu, 12 Feb 2009 14:24:51 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXhB3-0003kK-CB for automake@gnu.org; Thu, 12 Feb 2009 14:24:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXhB2-0003ib-Dp for automake@gnu.org; Thu, 12 Feb 2009 14:24:48 -0500 Received: from [199.232.76.173] (port=57841 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXhB2-0003iJ-A7 for automake@gnu.org; Thu, 12 Feb 2009 14:24:48 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:33378) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXhB1-0007Sa-Ju for automake@gnu.org; Thu, 12 Feb 2009 14:24:48 -0500 Received: from localhost.localdomain (xdsl-87-78-235-36.netcologne.de [87.78.235.36]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 90FEB400028FA; Thu, 12 Feb 2009 20:24:46 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LXhB0-0002mV-1g; Thu, 12 Feb 2009 20:24:46 +0100 Date: Thu, 12 Feb 2009 20:24:46 +0100 From: Ralf Wildenhues To: dagecko@free.fr Message-ID: <20090212192445.GA10625@ins.uni-bonn.de> Mail-Followup-To: dagecko@free.fr, automake@gnu.org References: <1671216860.725911234289161908.JavaMail.root@zimbra20-e3.priv.proxad.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1671216860.725911234289161908.JavaMail.root@zimbra20-e3.priv.proxad.net> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: automake and dist data X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:24:49 -0000 Hello, please don't top-post on this list; thanks. * dagecko@free.fr wrote on Tue, Feb 10, 2009 at 07:06:01PM CET: > > I'm developping a middle-scale library that uses autoconf and > automake. This library comes along with some demo and test programs. > Those demo and test programs now require some input files in order to > run. Those input files also have to be distributed with the package. I > actually tried to put those input data files into the header directory > and I also wondered if I could put them into the share subdirectory. You should definitely not put files other than header files into $(includedir), if that's what you mean. See here for the meaning of the directory variables: > The test programs will have to read those data, but I actually can't > know where those input data are stored (it is top_srcdir/include) but > it is somewhat impossible from what I know to give that directory to > C/C++ file functions. Of course, I can code that in the hard way. But > that will work as long as the project is not installed. But once > installed (on any uknown machine), I really can't know where to find > those input files. If they are installed in the include subdirectory, > then I can have a look at /usr/include, or it might be > /usr/local/include, or whatever directory a final user would have put > to configure. It is the same thing if I put those data in the share > subdirectory. This FAQ entry contains some information about this issue: Hope that helps. Cheers, Ralf From MAILER-DAEMON Thu Feb 12 14:26:22 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LXhCY-0006MV-15 for mharc-automake@gnu.org; Thu, 12 Feb 2009 14:26:22 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXhCV-0006IM-UM for automake@gnu.org; Thu, 12 Feb 2009 14:26:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXhCU-0006EI-7H for automake@gnu.org; Thu, 12 Feb 2009 14:26:19 -0500 Received: from [199.232.76.173] (port=57875 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXhCU-0006Ds-1h for automake@gnu.org; Thu, 12 Feb 2009 14:26:18 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:39906) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXhCT-0007hK-Mg for automake@gnu.org; Thu, 12 Feb 2009 14:26:17 -0500 Received: from localhost.localdomain (xdsl-87-78-235-36.netcologne.de [87.78.235.36]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 230464000268D; Thu, 12 Feb 2009 20:26:17 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LXhCS-0002mj-QP; Thu, 12 Feb 2009 20:26:16 +0100 Date: Thu, 12 Feb 2009 20:26:16 +0100 From: Ralf Wildenhues To: Michel Briand Message-ID: <20090212192616.GB10625@ins.uni-bonn.de> Mail-Followup-To: Michel Briand , automake@gnu.org References: <20090210111951.2976c1b8@eana.kheb.homelinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090210111951.2976c1b8@eana.kheb.homelinux.org> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: make dist and data package X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:26:20 -0000 Hello Michel, * Michel Briand wrote on Tue, Feb 10, 2009 at 11:19:51AM CET: > > I'm working on a project that release code/library but also a large > amount of data. > > I wonder if it's possible to create 2 packages with make dist. One for > the software, one for the data directory ? I see two possibilities: you can write a fully separate dist-data rule, that also has its own recursive makefile machinery (in case you are using SUBDIRS), and implement all that manually, or you can hook into the dist-hook. It is invoked after the population of $(distdir) in that Makefile. For example, you could put a data tarball creation in there, and then remove unneeded parts for the "normal" tarball. I'd recommend not splitting in any way such that the user needs more than one tarball. Hope that helps. Cheers, Ralf From MAILER-DAEMON Thu Feb 12 14:33:26 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LXhJO-0001rk-PJ for mharc-automake@gnu.org; Thu, 12 Feb 2009 14:33:26 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXhJN-0001rL-My for automake@gnu.org; Thu, 12 Feb 2009 14:33:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXhJM-0001r9-8q for automake@gnu.org; Thu, 12 Feb 2009 14:33:24 -0500 Received: from [199.232.76.173] (port=55070 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXhJM-0001r6-3R for automake@gnu.org; Thu, 12 Feb 2009 14:33:24 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:33267) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXhJL-0008Jf-JO for automake@gnu.org; Thu, 12 Feb 2009 14:33:23 -0500 Received: from localhost.localdomain (xdsl-87-78-235-36.netcologne.de [87.78.235.36]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 850B14000477C for ; Thu, 12 Feb 2009 20:33:22 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LXhJK-0002mx-6I for automake@gnu.org; Thu, 12 Feb 2009 20:33:22 +0100 Date: Thu, 12 Feb 2009 20:33:22 +0100 From: Ralf Wildenhues To: automake@gnu.org Message-ID: <20090212193321.GC10625@ins.uni-bonn.de> Mail-Followup-To: automake@gnu.org References: <20090203233801.GA6308@linux.vnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090203233801.GA6308@linux.vnet> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: AX_ADD_AM_MACRO creates circular dependencies X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:33:25 -0000 Hello Allan, * Allan Caffee wrote on Wed, Feb 04, 2009 at 12:38:01AM CET: > First of all I wasn't really sure where to start this thread so if > this isn't the appropriate place I apologize. This is very well appropriate here. > I've noticed that a handful of the packages in the Autoconf archives > use the macros AX_ADD_AM_MACRO and AX_ADD_RECURSIVE_AM_MACRO. These > macros add targets and variable assignments to a generated file > $(top_srcdir)/aminclude.am. Users are then intended to add a line > like > > include $(top_srcdir)/aminclude.am > > to whichever Makefile.am needs the provided functionality. The > problem with this is that Makefile.in now depends on aminclude.am. > And aminclude.am is created by configure. And in turn configure > cannot be run (successfully) without Makefile.in. So in order to even > get a useable build system the developer has to touch aminclude.am. Hmm, ok. > This circular dependency is inconvenient for developers but what's > even worse is that any user who tries to compile this project from a > source tarball must now have Automake installed. Yep. > Why? Because > aminclude.am is generated at configure-time and included Automake > files are inserted into the Makefile.in when Automake runs. This > means that (even if the actual contents of aminclude.am are identical > to those in the tarball) running ./configure && make on a source will > (detecting the change in a dependency of Makfile.am) automatically > rerun Automake. Agreed, too. If the aminclude.am file is to contain any stuff that is treated specially by automake, then I assume that is desired though. So really the question is whether aminclude.am should contain ordinary makefile rules, where it is further irrelevant whether automake knows about them or not; or whether aminclude.am may contain anything which needs interpreted by automake. In the latter case, the user simply needs 'automake', it would need to be run after configure is run. I'd provide an empty aminclude.am in the tarball, and let configure update it only in case its contents would change. In the other case, with ordinary makefile stuff only, I would include them in a way that is not visible to automake. Here's how to achieve this, for example: Use some AC_SUBST'ed variable, which expands to either the contents of the rule(s), or an include statement that includes your file. Now, the "normal" 'include' statement is interpreted by automake, at automake run time, while the 'make' 'include' statement is interpreted by make, at make run time. It is also in practice not completely portable, even though POSIX 2008 has now standardized one form of it (some make implementations use '.include', or put quotes around the file name). In fact, reading the documentation at , it recommends a method that uses such a substituted variable. Automake internally has a couple of substed variables for this, too. The respective statement looks like this: @am__include@ @am__quote@FILE@am__quote@ with FILE being the file to be included. Note that this relies on unpublished internal details, but in turn is portable to all kinds of make implementations. Hope that helps. Cheers, Ralf From MAILER-DAEMON Fri Feb 13 10:44:01 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LY0Cv-0001Xc-RJ for mharc-automake@gnu.org; Fri, 13 Feb 2009 10:44:01 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LY0Ct-0001Sx-ON for automake@gnu.org; Fri, 13 Feb 2009 10:43:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LY0Cs-0001QW-Pw for automake@gnu.org; Fri, 13 Feb 2009 10:43:59 -0500 Received: from [199.232.76.173] (port=35668 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LY0Cs-0001QB-KU for automake@gnu.org; Fri, 13 Feb 2009 10:43:58 -0500 Received: from el-out-1112.google.com ([209.85.162.180]:43003) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LY0Cs-0003j5-6X for automake@gnu.org; Fri, 13 Feb 2009 10:43:58 -0500 Received: by el-out-1112.google.com with SMTP id b25so808843elf.12 for ; Fri, 13 Feb 2009 07:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=MUWlduDQu59Z8iacc84Y0yyhgjbuP8Y0Hqv61Z5rg+g=; b=chnnFCCln5JpqpDTrLjt2yScFKkw+yR+7cIBNvjVaggdxLXTiUirdd9b2+85CsRKuZ GpGLsE2nR2pOYtutIesJ4N7HN0ME75lycpA5liWPAfVIoxqGJs127c3e7whzXTn96rAG 5Sn9eO6Y5nnY1UttlSI7IdeHGSJrStjoSUd3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qslE6ya/ndnqyL37jnfw124rvqMpumBtmHWY9kUDrz9MBKc+4R9ZgQSA/odzlugGcM 041tJ4rEMy5nGOmDyc8AOKIbOxLyGcRv7kKAPEUNro+CnXFCoDwuAn+TK4JIrexnqAMy svfRczGW2POBr7vuuQXB3/j17evxc2Tvl8zoM= MIME-Version: 1.0 Received: by 10.220.73.194 with SMTP id r2mr666022vcj.76.1234539835153; Fri, 13 Feb 2009 07:43:55 -0800 (PST) In-Reply-To: <20090212193321.GC10625@ins.uni-bonn.de> References: <20090203233801.GA6308@linux.vnet> <20090212193321.GC10625@ins.uni-bonn.de> Date: Fri, 13 Feb 2009 10:43:55 -0500 Message-ID: From: Allan Caffee To: automake@gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: AX_ADD_AM_MACRO creates circular dependencies X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:44:00 -0000 On Thu, 12 Feb 2009, Ralf Wildenhues wrote: > > I've noticed that a handful of the packages in the Autoconf archives > > use the macros AX_ADD_AM_MACRO and AX_ADD_RECURSIVE_AM_MACRO. These > > macros add targets and variable assignments to a generated file > > $(top_srcdir)/aminclude.am. Users are then intended to add a line > > like > > > > include $(top_srcdir)/aminclude.am > > > > to whichever Makefile.am needs the provided functionality. The > > problem with this is that Makefile.in now depends on aminclude.am. > > And aminclude.am is created by configure. And in turn configure > > cannot be run (successfully) without Makefile.in. So in order to even > > get a useable build system the developer has to touch aminclude.am. > > Hmm, ok. Actually I've done a little more research here and it turns out that my initial understanding was flawed, which brings me to one of your later points. > In the other case, with ordinary makefile stuff only, I would include > them in a way that is not visible to automake. [...] > In fact, reading the documentation at > , > it recommends a method that uses such a substituted variable. Right you are, the user is instead expected to place @INC_AMINCLUDE@ in the Makefile.am. As you suggested this hides the inclusion from Automake. AX_ADD_AM_MACRO does not create Automake rules as the name would suggest but rather it creates _Make_ rules. Of course relying on includes like this in turn makes the build system less portible (as you mentioned). Ideally the macro archive would provide a way to produce these rules in a way that they would be available for Automake to work its magic. I'm working on a patch series that would allow macro developers provide an Automake include-able file which will be available before Automake is run. I'd be happy to CC this list if there is no objection. > Automake internally has a couple of substed variables for this, too. > The respective statement looks like this: > @am__include@ @am__quote@FILE@am__quote@ Yes that's how Automake manages to provide dependencies as a side effect of compilation, right? I remember abusing this at one point to get the Autotools to make use of some automatic dependencies generated by a script of mine. :) Allan From MAILER-DAEMON Mon Feb 16 16:58:04 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LZBTY-0002nr-B5 for mharc-automake@gnu.org; Mon, 16 Feb 2009 16:58:04 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZBTW-0002nk-SR for automake@gnu.org; Mon, 16 Feb 2009 16:58:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZBTU-0002nP-M4 for automake@gnu.org; Mon, 16 Feb 2009 16:58:01 -0500 Received: from [199.232.76.173] (port=57462 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZBTU-0002nM-Hx for automake@gnu.org; Mon, 16 Feb 2009 16:58:00 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:53779) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZBTT-0004ye-CO for automake@gnu.org; Mon, 16 Feb 2009 16:57:59 -0500 Received: from localhost.localdomain (xdsl-87-78-108-48.netcologne.de [87.78.108.48]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id A6DD4400024EB; Mon, 16 Feb 2009 22:57:58 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LZBTW-0003wL-AQ; Mon, 16 Feb 2009 22:58:02 +0100 Date: Mon, 16 Feb 2009 22:58:02 +0100 From: Ralf Wildenhues To: Jan Engelhardt Message-ID: <20090216215801.GM5813@ins.uni-bonn.de> Mail-Followup-To: Jan Engelhardt , automake@gnu.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Automake_flags not override X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:58:03 -0000 Hi Jan, sorry for the long delay. * Jan Engelhardt wrote on Fri, Jan 02, 2009 at 08:00:21PM CET: > > given a configure.ac which defines AM_INIT_AUTOMAKE([-Wall]), > running `automake -Wnone` still produces the warnings I had with -Wall. > I think command line should override any earlier flags. For what it's worth, that would have been my expectation as well: AM_INIT_AUTOMAKE([OPTIONS]...) should apply to all Makefile.in files, and should be overridden by per-Makefile.am AUTOMAKE_OPTIONS = [OPTIONS]... which in turn should be overridden by automake [OPTIONS]... However, the latter semantics is not documented anywhere in the manual, and is not the case either. What really happens is that the command-line options are interpreted first (way earlier than the others, in parse_arguments, after parse_WARNINGS). As to why it works this way: I'm pretty sure there was a good reason to go this way. I haven't found a definite answer in the history or mail archives yet, but I think it might be this: automake stores some arguments in the rebuild rule for the Makefile.in files (the "strictness", and --ignore-deps if applicable). Now, when the user changes these options, say, in configure.ac, then types 'make', a rebuild will invoke automake with those old options that are still in the Makefile. In that case it would be better if the command line options are overridden by those from the newer file; otherwise you could never change them without also manually invoking the autotools yourself. I suppose the priority ordering for warnings was intended to not differ from that of these flags. Not sure though, and I currently don't yet see which kind of change would be an obvious improvement. Cheers, Ralf From MAILER-DAEMON Wed Feb 18 17:45:41 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LZvAj-0008Jr-Ih for mharc-automake@gnu.org; Wed, 18 Feb 2009 17:45:41 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZvAg-0008IE-Uc for automake@gnu.org; Wed, 18 Feb 2009 17:45:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZvAf-0008GT-85 for automake@gnu.org; Wed, 18 Feb 2009 17:45:38 -0500 Received: from [199.232.76.173] (port=54049 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZvAf-0008GM-5b for automake@gnu.org; Wed, 18 Feb 2009 17:45:37 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:47157) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1LZvAe-0006wo-Ml for automake@gnu.org; Wed, 18 Feb 2009 17:45:36 -0500 X-IronPort-AV: E=Sophos;i="4.38,231,1233529200"; d="scan'208";a="21343331" Received: from netchaiev.zarb.org (HELO oberkampf.msr-inria.inria.fr) ([82.224.237.5]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2009 23:45:33 +0100 Message-ID: <499C8F99.8060100@inria.fr> Date: Wed, 18 Feb 2009 23:45:45 +0100 From: Guillaume Rousse User-Agent: Thunderbird 2.0.0.19 (X11/20081231) MIME-Version: 1.0 To: automake@gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Using gettext support with an external xgettext program ? X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:45:39 -0000 Hello list. I'm trying to sanitize sympa (www.sympa.org) usage of autotools. I made a few attempts to use automake builtin gettext support, as explained at http://www.lrde.epita.fr/~adl/autotools.html, but I don't think that is really suited for my needs. First, sympa is mainly a perl program, and the only native parts are only wrapper without any translation, meaing I don't need any support for libintl linking. Second, many of the strings to be translated occurs in tt2 template files, and xgettext.pl (distributed in Locale-Maketext-Lexicon) does a far better job than GNU xgexttext to extract them (I don't think gnu gettext could recognize patterns such as [% |l(args) %]string[% END %], even with --keyword option). So, is there a way to benefit from automake-generated make rules for managing (building, installing, distributing, etc...) .pot, .mo and .po files, but with an external xgettext program ? Or should I manage this just as ordinary data files, such as: localedir = $(datadir)/locale nobase_locale_DATA = fr_FR/LC_MESSAGES/sympa.mo \ ... Thanks. -- BOFH excuse #184: loop found in loop in redundant loopback From MAILER-DAEMON Wed Feb 18 19:14:07 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LZwYJ-0005ey-D4 for mharc-automake@gnu.org; Wed, 18 Feb 2009 19:14:07 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZwYG-0005aZ-U5 for automake@gnu.org; Wed, 18 Feb 2009 19:14:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZwYF-0005YD-TS for automake@gnu.org; Wed, 18 Feb 2009 19:14:04 -0500 Received: from [199.232.76.173] (port=41958 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZwYF-0005Xc-9d for automake@gnu.org; Wed, 18 Feb 2009 19:14:03 -0500 Received: from smarthost.piip.techfak.uni-bielefeld.de ([129.70.137.17]:57220 helo=smarthost.TechFak.Uni-Bielefeld.DE) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LZwYE-0007n9-Na for automake@gnu.org; Wed, 18 Feb 2009 19:14:03 -0500 Received: from asahi.TechFak.Uni-Bielefeld.DE (asahi.TechFak.Uni-Bielefeld.DE [129.70.137.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 88A0048251 for ; Thu, 19 Feb 2009 01:13:56 +0100 (CET) X-Authentication-Warning: asahi.TechFak.Uni-Bielefeld.DE: rhomann owned process doing -bs Date: Thu, 19 Feb 2009 01:13:56 +0100 (MET) From: Robert Homann To: automake@gnu.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Using ylwrap in parallel builds fails sometimes X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:14:05 -0000 Hi all! I have some trouble building a yacc parser with Automake (using ylwrap) in a parallel build. Usually, make -j runs fine on my project with no errors, but it fails occasionally when trying to build the parser. Here is a stripped down test case that demonstrates what I'm doing (using Autoconf 2.63, Automake 1.10.2): =============== configure.ac: --------------- AC_PREREQ([2.63]) AC_INIT([testing],[0.1],[does@not.exist]) AM_INIT_AUTOMAKE([-Wall foreign]) AC_CONFIG_SRCDIR([parser.y]) AC_CONFIG_HEADERS([config.h]) AC_PROG_CC AM_PROG_LEX AC_PROG_YACC AC_PROG_RANLIB YFLAGS="${YFLAGS} -d" AC_CONFIG_FILES([Makefile]) AC_OUTPUT =============== =============== Makefile.am: --------------- noinst_LIBRARIES=libparser.a libparser_a_SOURCES=parser.y scanner.l =============== =============== parser.y --------------- %{ #ifdef HAVE_CONFIG_H #include #endif /* HAVE_CONFIG_H */ int yylex (void); void yyerror (char const *); %} %token NUM %token STRING %token OP %% input: NUM ; =============== =============== scanner.l --------------- %{ #ifdef HAVE_CONFIG_H #include #endif /* HAVE_CONFIG_H */ #include #include "parser.h" %} %% [0-9]+ return NUM; %% int yyerror(const char *err) { fprintf(stderr,"Error.\n"); return -1; } =============== With only these four files in some directory, execute the following commands: $ autoreconf -i configure.ac:3: installing `./install-sh' configure.ac:3: installing `./missing' Makefile.am: installing `./depcomp' configure.ac: installing `./ylwrap' $ ./configure ... $ STOP=0; while test $STOP -eq 0; do make clean && rm -f parser.[ch] scanner.c && make -j || STOP=1; done The last line cleans up the project and performs a parallel build again and again until it fails -- and it does fail after a couple of runs, sometimes straight after the first one, sometimes after 10 or even more, like this: [...] /bin/bash ./ylwrap parser.y y.tab.c parser.c y.tab.h parser.h y.output parser.output -- bison -y -d /bin/bash ./ylwrap scanner.l lex.yy.c scanner.c -- flex gcc -DHAVE_CONFIG_H -I. -g -O2 -MT scanner.o -MD -MP -MF .deps/scanner.Tpo -c -o scanner.o scanner.c scanner.l:6:20: error: parser.h: No such file or directory updating parser.h gcc -DHAVE_CONFIG_H -I. -g -O2 -MT parser.o -MD -MP -MF .deps/parser.Tpo -c -o parser.o parser.c scanner.l: In function `yylex': scanner.l:9: error: `NUM' undeclared (first use in this function) scanner.l:9: error: (Each undeclared identifier is reported only once scanner.l:9: error: for each function it appears in.) make[1]: *** [scanner.o] Error 1 [...] The file parser.h should have been generated by ylwrap/bison before compiling scanner.c, but apparently this is not always the case. I can reproduce this on Linux/amd64 (Ubuntu 8.10, dual core) and on Solaris 10/i386 (dual core), using GNU Make 3.81 on both machines. The problem seems to go away, however, when using pmake -j 4 (NetBSD make) on my Linux machine. Now, did I forget to add some additional rules to Makefile.am? Or do you think I have hit a bug in ylwrap or in GNU Make? Best regards, Robert Homann -- Windows is not the answer. Windows is the question. The answer is "No". From MAILER-DAEMON Sun Feb 22 16:22:33 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbLmT-0003ao-JP for mharc-automake@gnu.org; Sun, 22 Feb 2009 16:22:33 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbLmR-0003ZX-IS for automake@gnu.org; Sun, 22 Feb 2009 16:22:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbLmQ-0003ZG-Np for automake@gnu.org; Sun, 22 Feb 2009 16:22:30 -0500 Received: from [199.232.76.173] (port=58704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbLmQ-0003ZD-Gu for automake@gnu.org; Sun, 22 Feb 2009 16:22:30 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]:52542) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1LbLmQ-0002LT-05 for automake@gnu.org; Sun, 22 Feb 2009 16:22:30 -0500 X-IronPort-AV: E=Sophos;i="4.38,251,1233529200"; d="scan'208";a="35582412" Received: from netchaiev.zarb.org (HELO oberkampf.msr-inria.inria.fr) ([82.224.237.5]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2009 22:22:26 +0100 Message-ID: <49A1C226.2050608@inria.fr> Date: Sun, 22 Feb 2009 22:22:46 +0100 From: Guillaume Rousse User-Agent: Thunderbird 2.0.0.19 (X11/20081231) MIME-Version: 1.0 To: bug-gnu-utils@gnu.org, automake@gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Subject: autoreconf doesn't install Makefile.in.in files if AM_GNU_GETTEXT_VERSION is not used X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:22:31 -0000 Hello list. I'm trying to use automake builtin support for a perl project (sympa). According to the gettext manual, I only need AM_PO_SUBDIRS macro, not AM_GNU_GETTEXT_VERSION, as I only need PO files handling, and not native code linking support. However, this is not enough to have autoreconf create Makefile.in.in files in po directories (I have two of them), as it considers gettext is not used: [guillaume@oberkampf sympa-autotools-cleanup]$ autoreconf -v autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --no-force autoreconf: Leaving directory `.' If I try to invoke gettextize manually, it only creates Makefile.in.in in the po directory, and not in the additional po-wwsympa one (I have two pot files, hence the need for an additional directory), and also add a lot of uneeded m4 files: [guillaume@oberkampf sympa-autotools-cleanup]$ gettextize Copying file ABOUT-NLS Copying file config.rpath Not copying intl/ directory. Copying file po/Makefile.in.in Copying file po/boldquot.sed Copying file po/en@boldquot.header Copying file po/en@quot.header Copying file po/insert-header.sin Copying file po/Makevars.template Copying file po/quot.sed Copying file po/remove-potcdate.sin Copying file po/Rules-quot Adding an entry to po/ChangeLog (backup is in po/ChangeLog~) Copying file m4/gettext.m4 Copying file m4/iconv.m4 Copying file m4/lib-ld.m4 Copying file m4/lib-link.m4 Copying file m4/lib-prefix.m4 Copying file m4/nls.m4 Copying file m4/po.m4 Copying file m4/progtest.m4 Updating configure.ac (backup is in configure.ac~) Adding an entry to ChangeLog (backup is in ChangeLog~) Please use AM_GNU_GETTEXT([external]) in order to cause autoconfiguration to look for an external libintl. Please run 'aclocal -I m4' to regenerate the aclocal.m4 file. You need aclocal from GNU automake 1.9 (or newer) to do this. Then run 'autoconf' to regenerate the configure file. You might also want to copy the convenience header file gettext.h from the /usr/share/gettext directory into your package. It is a wrapper around that implements the configure --disable-nls option. Press Return to acknowledge the previous three paragraphs. autopoint doesn't works either: [guillaume@oberkampf sympa-autotools-cleanup]$ autopoint autopoint: *** Missing version: please specify in configure.ac through a line 'AM_GNU_GETTEXT_VERSION(x.yy.zz)' the gettext version the package is using autopoint: *** Stop. Does it means I'm condemned to import two generated Makefile.in.in files in the repository, or to use a wrapper over autoreconf to handle this specific case ? From MAILER-DAEMON Mon Feb 23 00:22:18 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbTGj-00025O-Qo for mharc-automake@gnu.org; Mon, 23 Feb 2009 00:22:17 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbTGg-00024m-VC for automake@gnu.org; Mon, 23 Feb 2009 00:22:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbTGf-00024S-G4 for automake@gnu.org; Mon, 23 Feb 2009 00:22:14 -0500 Received: from [199.232.76.173] (port=53427 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbTGf-00024P-9e for automake@gnu.org; Mon, 23 Feb 2009 00:22:13 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:47747) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbTGf-0005Cc-3W for automake@gnu.org; Mon, 23 Feb 2009 00:22:13 -0500 Received: by qyk13 with SMTP id 13so2816426qyk.18 for ; Sun, 22 Feb 2009 21:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=cHBBH0EnyxUIs8WFL7nuE/OhcR5Otw+Vd70ssnSMcAo=; b=RQdg9dTt45hUs0LIPUmntxdstuA4wN+DKvSLDIMYzPGzJp3KFMEmdkoQ+DJfTI9qGg /egQPQyAgujjHcbGqI5C7p6PvPzA+0qYeWDpk1CnyayyI7+5KPK8swf3UPZ9ZMO2x2C5 AzNDr8SWmjszPgeR0Q7kXCHKMjokUzIsZTv7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=SvIAZJQkKyqMZl0rCXnjVXl/MRvJOdmpaw+rICKDdGaDUh9KhBtCO4bqx8Hcn/fPC8 V8Oil/88pq8Edf2fT/0N9uxGRcXueTEzYL8f2/INLx4rtgTGEBFqIhO9lUJ4BXyId07E 0ZfCafcw5idgu8YTEgj7TGMihe5scgsyeBY1k= MIME-Version: 1.0 Received: by 10.224.37.13 with SMTP id v13mr5320653qad.129.1235366532137; Sun, 22 Feb 2009 21:22:12 -0800 (PST) Date: Sun, 22 Feb 2009 22:22:12 -0700 Message-ID: From: Tavian Barnes To: automake@gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Built sources and make distcheck X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 05:22:15 -0000 I have a project which auto-generates some look-up tables when checked out from its SCM, and are distributed in the tarballs. These tables used to be made by shell scripts called from autogen.sh, but I recently ported them to C for a massive speed improvement. I've implemented the Makefile.am like this: EXTRA_PROGRAMS = generate generate_SOURCES = generate.c generated.c: generate ./generate$(EXEEXT) >$@ bin_PROGRAMS = lookup lookup_SOURCES = lookup.c generated.c This is almost right, but because generated.c gets distributed but `generate' doesn't, make sees generated.c as out-of-date in the tarballs, and re-builds it. This is worse when `make distcheck' is run, because of the VPATH build; $@ isn't even the right location to write to, and the source directory is read-only anyway, so a qualified path wouldn't help. Is there any way to not build the `generate' target if generated.c exists, but still build it when it doesn't? Thanks, -- Tavian Barnes From MAILER-DAEMON Mon Feb 23 04:39:04 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbXHE-0008TV-2l for mharc-automake@gnu.org; Mon, 23 Feb 2009 04:39:04 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbXHB-0008T5-PA for automake@gnu.org; Mon, 23 Feb 2009 04:39:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbXH8-0008Rw-LR for automake@gnu.org; Mon, 23 Feb 2009 04:39:00 -0500 Received: from [199.232.76.173] (port=58944 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbXH8-0008Rt-Eb for automake@gnu.org; Mon, 23 Feb 2009 04:38:58 -0500 Received: from smarthost.piip.techfak.uni-bielefeld.de ([129.70.137.17]:54425 helo=smarthost.TechFak.Uni-Bielefeld.DE) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LbXH7-0001tP-UO for automake@gnu.org; Mon, 23 Feb 2009 04:38:58 -0500 Received: from padouk.TechFak.Uni-Bielefeld.DE (padouk.TechFak.Uni-Bielefeld.DE [129.70.128.101]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id BF3AB48243 for ; Mon, 23 Feb 2009 10:38:51 +0100 (CET) X-Authentication-Warning: padouk.TechFak.Uni-Bielefeld.DE: rhomann owned process doing -bs Date: Mon, 23 Feb 2009 10:38:51 +0100 (MET) From: Robert Homann To: automake@gnu.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: Using ylwrap in parallel builds fails sometimes X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:39:02 -0000 On Thu, 19 Feb 2009, Robert Homann wrote: Hi again! > I have some trouble building a yacc parser with Automake (using > ylwrap) in a parallel build. Usually, make -j runs fine on my project Replying to myself, adding the dependency scanner.c: parser.c to Makefile.am works fine (thanks to Ruediger Ranft for the suggestion). As a side note, I looked through the Automake manual once again and found another suggestion there (section 8.8, Yacc and Lex support), which told me to add BUILT_SOURCES = parser.h to Makefile.am. This, however, did not work for me (make doesn't know how to build parser.h). Putting parser.c into BUILT_SOURCES instead was fine again. Best regards, Robert Homann -- Windows is not the answer. Windows is the question. The answer is "No". From MAILER-DAEMON Mon Feb 23 04:42:16 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbXKK-0000ov-5H for mharc-automake@gnu.org; Mon, 23 Feb 2009 04:42:16 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbXKH-0000o1-Hc for automake@gnu.org; Mon, 23 Feb 2009 04:42:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbXKF-0000nL-OO for automake@gnu.org; Mon, 23 Feb 2009 04:42:12 -0500 Received: from [199.232.76.173] (port=34687 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbXKF-0000nC-8V for automake@gnu.org; Mon, 23 Feb 2009 04:42:11 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:47138) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbXKE-0002wE-Mr for automake@gnu.org; Mon, 23 Feb 2009 04:42:11 -0500 Received: from localhost.localdomain (xdsl-87-78-163-0.netcologne.de [87.78.163.0]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 393AC40004869; Mon, 23 Feb 2009 10:42:08 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LbXKB-0003cG-UB; Mon, 23 Feb 2009 10:42:07 +0100 Date: Mon, 23 Feb 2009 10:42:07 +0100 From: Ralf Wildenhues To: Tavian Barnes Message-ID: <20090223094207.GA13679@ins.uni-bonn.de> Mail-Followup-To: Tavian Barnes , automake@gnu.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Built sources and make distcheck X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:42:14 -0000 Hello Tavian, * Tavian Barnes wrote on Mon, Feb 23, 2009 at 06:22:12AM CET: > EXTRA_PROGRAMS = generate > generate_SOURCES = generate.c > > generated.c: generate BTW, the prerequisite here would need to be generate$(EXEEXT). > ./generate$(EXEEXT) >$@ > > bin_PROGRAMS = lookup > lookup_SOURCES = lookup.c generated.c You need to use BUILT_SOURCES, and fake dependencies so that no distributed file depends on an undistributed one. Untested: EXTRA_PROGRAMS = generate BUILT_SOURCES = generate$(EXEEXT) generated.c: generate.c Makefile.in ./generate$(EXEEXT) >$@ bin_PROGRAMS = lookup lookup_SOURCES = lookup.c generated.c > This is almost right, but because generated.c gets distributed but > `generate' doesn't, make sees generated.c as out-of-date in the > tarballs, and re-builds it. This is worse when `make distcheck' is > run, because of the VPATH build; $@ isn't even the right location to > write to, generated.c can live in the source or in the build tree. But given that different make implementations have slightly different VPATH semantics, it may be useful to require it to always live in the source tree; further, it may be useful to update it lazily (this shouldn't matter for read-only trees iff your dependencies are set up correctly, but it should make for faster rebuilds): $(srcdir)/generated.c: generate.c Makefile.in ./generate$(EXEEXT) > tmp-generated.c if diff tmp-generated.c $@ >/dev/null 2>&1; then \ rm -f tmp-generated.c; \ else \ mv -f tmp-generated.c $@; \ fi lookup_SOURCES = lookup.c $(srcdir)/generated.c > and the source directory is read-only anyway, so a qualified > path wouldn't help. Is there any way to not build the `generate' > target if generated.c exists, but still build it when it doesn't? Hope that helps. Cheers, Ralf From MAILER-DAEMON Mon Feb 23 10:01:40 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbcJP-0007VV-Sv for mharc-automake@gnu.org; Mon, 23 Feb 2009 10:01:39 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbcJN-0007Ti-Pw for automake@gnu.org; Mon, 23 Feb 2009 10:01:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbcJM-0007S6-AT for automake@gnu.org; Mon, 23 Feb 2009 10:01:37 -0500 Received: from [199.232.76.173] (port=41780 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbcJM-0007Rk-0U for automake@gnu.org; Mon, 23 Feb 2009 10:01:36 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:40219) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbcJL-0007Td-HD for automake@gnu.org; Mon, 23 Feb 2009 10:01:35 -0500 Received: by qyk13 with SMTP id 13so2992494qyk.18 for ; Mon, 23 Feb 2009 07:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=AMCNyn+TX473OuItOIhjgBV7ZRJ9+jSoJvm5FKtqTKE=; b=HChjbyvhSJ2b78ceKOaPZlG8NNmc+zyrgeYDDzSzTeNZKC+MZzcmDi0iJaPOUa7A4j YvGfl29SU0EE/C+XGSoQVGlnZGzXxX5fM1gQkhMb7qIiXRLVcmHg9eA6G6ox8wi+n9Nk 6a4LXNf8lQBDupDlVmCsPGds1xCxg8Wod3eDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=LjfEnxZ4rlTlZ7pDw+WaAlWrXvrwKdHtIRT/i33MQt4tcwh22n2mYYceEu793PWn6U FF26txIyz5r4FmVeqA5+ai0fHzvM/we5CGai9CPFo7FDgjhgP3yk2WdU1wbQ0LzEfvz/ yaqKMZZ5FliI/Mo+MdYRLezMPtTzJVv4EoUt4= MIME-Version: 1.0 Received: by 10.224.67.10 with SMTP id p10mr6073205qai.264.1235401294511; Mon, 23 Feb 2009 07:01:34 -0800 (PST) Date: Mon, 23 Feb 2009 16:01:34 +0100 Message-ID: <670992c60902230701h46b5e1b7nf683c16788f612ef@mail.gmail.com> From: =?UTF-8?B?TWF0xJtqICBUw73EjQ==?= To: GNU Automake mailing list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: make dvi during make distcheck too annoying X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:01:38 -0000 Hello, I use automake in one of my project along with texinfo. That project has documentation full of images. As you probably know, 'make pdf' makes a PDF document from JPGs and PNGs, whereas 'make dvi' requires EPSs. However, EPS images are insanely large (in this case like 15 times larger than JPGs). The problem is that running 'make distcheck' results in error since the EPS images that should be there aren't there and 'make distcheck' tries to run 'make dvi' everywhere. I would like to run 'make pdf' instead or at least to disable building DVI. Is there any way to accomplish that? Regards, Matej From MAILER-DAEMON Mon Feb 23 11:10:34 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbdO6-00025G-B8 for mharc-automake@gnu.org; Mon, 23 Feb 2009 11:10:34 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbdO4-000253-Nq for automake@gnu.org; Mon, 23 Feb 2009 11:10:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbdO3-00024n-Tc for automake@gnu.org; Mon, 23 Feb 2009 11:10:32 -0500 Received: from [199.232.76.173] (port=49205 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbdO3-00024k-OG for automake@gnu.org; Mon, 23 Feb 2009 11:10:31 -0500 Received: from qw-out-1920.google.com ([74.125.92.146]:55489) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbdO3-0007b0-4r for automake@gnu.org; Mon, 23 Feb 2009 11:10:31 -0500 Received: by qw-out-1920.google.com with SMTP id 4so565945qwk.24 for ; Mon, 23 Feb 2009 08:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HzgsCr7qbj+6P/PyzVTbC/B17qjopZPXeLVQBHZf7bA=; b=b+ZjZIGeZNqvPxG6Wzij8EHAFo0ogT6h/bqKMz9mHVU4eeuYjCffel615j1MM6iifA e+FGppEyjB3zETUTlejS0XECRT8WZ+b42DWaFIOVS+FQrAeThhojAo7yWlx4BXXzHJiw JPQpEbd03ZpRyRtF/yBJg83NXvm3aXScHZHnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=kMOwhl0GPSRk8OcFFWC7wfzMzCAriSj6kHdBEs0OaCrKyURWYz0XwmvzAPbMIF1H8/ SODsMFdpMYRxCtWDEXO7u2TuBKXcvsI2QlKteSiHmzs1nOVrV28+kwMXicpglBHEBOPy cVlrxh7lF4C3/AziNM+zHfPhft2Kdi+vZoddM= MIME-Version: 1.0 Received: by 10.224.37.139 with SMTP id x11mr6238041qad.150.1235405429670; Mon, 23 Feb 2009 08:10:29 -0800 (PST) In-Reply-To: <20090223094207.GA13679@ins.uni-bonn.de> References: <20090223094207.GA13679@ins.uni-bonn.de> Date: Mon, 23 Feb 2009 09:10:29 -0700 Message-ID: From: Tavian Barnes To: Tavian Barnes , automake@gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Subject: Re: Built sources and make distcheck X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:10:32 -0000 2009/2/23 Ralf Wildenhues : > Hello Tavian, > > * Tavian Barnes wrote on Mon, Feb 23, 2009 at 06:22:12AM CET: >> EXTRA_PROGRAMS = generate >> generate_SOURCES = generate.c >> >> generated.c: generate > > BTW, the prerequisite here would need to be generate$(EXEEXT). Oh, right. >> ./generate$(EXEEXT) >$@ >> >> bin_PROGRAMS = lookup >> lookup_SOURCES = lookup.c generated.c > > You need to use BUILT_SOURCES, and fake dependencies so that no > distributed file depends on an undistributed one. Untested: > > EXTRA_PROGRAMS = generate > BUILT_SOURCES = generate$(EXEEXT) > generated.c: generate.c Makefile.in > ./generate$(EXEEXT) >$@ > bin_PROGRAMS = lookup > lookup_SOURCES = lookup.c generated.c Great, thanks! >> This is almost right, but because generated.c gets distributed but >> `generate' doesn't, make sees generated.c as out-of-date in the >> tarballs, and re-builds it. This is worse when `make distcheck' is >> run, because of the VPATH build; $@ isn't even the right location to >> write to, > > generated.c can live in the source or in the build tree. But given that > different make implementations have slightly different VPATH semantics, > it may be useful to require it to always live in the source tree; > further, it may be useful to update it lazily (this shouldn't matter for > read-only trees iff your dependencies are set up correctly, but it > should make for faster rebuilds): > > $(srcdir)/generated.c: generate.c Makefile.in > ./generate$(EXEEXT) > tmp-generated.c > if diff tmp-generated.c $@ >/dev/null 2>&1; then \ > rm -f tmp-generated.c; \ > else \ > mv -f tmp-generated.c $@; \ > fi > > lookup_SOURCES = lookup.c $(srcdir)/generated.c I've got it living in $(srcdir) now, thanks. I can't see why your version of a lazy update would speed it up though. It still runs ./generate, and now it's running diff too, right? >> and the source directory is read-only anyway, so a qualified >> path wouldn't help. Is there any way to not build the `generate' >> target if generated.c exists, but still build it when it doesn't? > > Hope that helps. > > Cheers, > Ralf > It did. Thanks again. -- Tavian Barnes From MAILER-DAEMON Tue Feb 24 03:20:18 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbsWY-0004gW-5G for mharc-automake@gnu.org; Tue, 24 Feb 2009 03:20:18 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbsWW-0004fJ-M7 for automake@gnu.org; Tue, 24 Feb 2009 03:20:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbsWV-0004f2-29 for automake@gnu.org; Tue, 24 Feb 2009 03:20:16 -0500 Received: from [199.232.76.173] (port=52543 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbsWU-0004ez-S9 for automake@gnu.org; Tue, 24 Feb 2009 03:20:14 -0500 Received: from mx20.gnu.org ([199.232.41.8]:52071) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LbsWU-0005x1-Ap for automake@gnu.org; Tue, 24 Feb 2009 03:20:14 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbsWT-000309-8f for automake@gnu.org; Tue, 24 Feb 2009 03:20:13 -0500 Received: from localhost.localdomain (xdsl-87-78-166-113.netcologne.de [87.78.166.113]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 470374000097D; Tue, 24 Feb 2009 09:20:11 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LbsWQ-0003qo-5S; Tue, 24 Feb 2009 09:20:10 +0100 Date: Tue, 24 Feb 2009 09:20:09 +0100 From: Ralf Wildenhues To: =?utf-8?B?TWF0xJtqIFTDvcSN?= Message-ID: <20090224082009.GA14751@ins.uni-bonn.de> Mail-Followup-To: =?utf-8?B?TWF0xJtqIFTDvcSN?= , GNU Automake mailing list References: <670992c60902230701h46b5e1b7nf683c16788f612ef@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <670992c60902230701h46b5e1b7nf683c16788f612ef@mail.gmail.com> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) Content-Transfer-Encoding: quoted-printable X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: GNU Automake mailing list Subject: Re: make dvi during make distcheck too annoying X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 08:20:17 -0000 Hello Mat=C4=9Bj, * Mat=C4=9Bj T=C3=BD=C4=8D wrote on Mon, Feb 23, 2009 at 04:01:34PM CET: > The problem is that running 'make distcheck' results in error since > the EPS images that should be there aren't there and 'make distcheck' > tries to run 'make dvi' everywhere. > I would like to run 'make pdf' instead or at least to disable building = DVI. You can overwrite the target in order to disable it: dvi: Cheers, Ralf From MAILER-DAEMON Tue Feb 24 18:43:11 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lc6vf-00042H-79 for mharc-automake@gnu.org; Tue, 24 Feb 2009 18:43:11 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lc6vd-00041Q-2S for automake@gnu.org; Tue, 24 Feb 2009 18:43:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lc6vc-000413-Bp for automake@gnu.org; Tue, 24 Feb 2009 18:43:08 -0500 Received: from [199.232.76.173] (port=45619 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lc6vc-00040y-0W for automake@gnu.org; Tue, 24 Feb 2009 18:43:08 -0500 Received: from mail-gx0-f160.google.com ([209.85.217.160]:59646) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lc6vb-0004k5-OL for automake@gnu.org; Tue, 24 Feb 2009 18:43:07 -0500 Received: by gxk4 with SMTP id 4so7869125gxk.18 for ; Tue, 24 Feb 2009 15:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=L+hy4d0buL4Vpc6E/KC924wbUYtbm4UdO1C/uE0W4/0=; b=pT//sloxUk/geXNsipTAIawH7KAtzOSDmivCMbCWf0hob9vGWxb/xDLeHIs5tySZnb pVCanXe8OYCAQvSugdwuGN4ARyg+WhIjHAddX0xea590W0sRpW1S7d6bNxPBew1eFhV4 Euj8MUUdwkK6WnUUA9f7ASwJ/APGTIOx1RFtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=i4JrnxqQXgE24Y0BlsvG7M4/GGbwDVIMpHExicSnBeNu1XiyN5b8Ra1rokv4b5OpGc kATndURQE8T6yRdU9fgYnehtPBTRkescSU1tVr4YJREsPEICJa/yiKn8keZ+L/o+vm8K WcnAHmHOdrpUHDjG7hjktuwUl+GZWDbRvfhms= Received: by 10.90.35.15 with SMTP id i15mr2493535agi.101.1235518986255; Tue, 24 Feb 2009 15:43:06 -0800 (PST) Received: from linux.vnet (pool-71-185-49-127.phlapa.fios.verizon.net [71.185.49.127]) by mx.google.com with ESMTPS id 7sm353230aga.26.2009.02.24.15.43.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 15:43:05 -0800 (PST) Date: Tue, 24 Feb 2009 18:43:02 -0500 From: Allan Caffee To: Tavian Barnes Message-ID: <20090224234302.GA6732@linux.vnet> Mail-Followup-To: Tavian Barnes , automake@gnu.org References: <20090223094207.GA13679@ins.uni-bonn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: automake@gnu.org Subject: Re: Built sources and make distcheck X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:43:09 -0000 On Mon, 23 Feb 2009, Tavian Barnes wrote: > 2009/2/23 Ralf Wildenhues : > [...] > > generated.c can live in the source or in the build tree. But given that > > different make implementations have slightly different VPATH semantics, > > it may be useful to require it to always live in the source tree; > > further, it may be useful to update it lazily (this shouldn't matter for > > read-only trees iff your dependencies are set up correctly, but it > > should make for faster rebuilds): > > > > $(srcdir)/generated.c: generate.c Makefile.in > > ./generate$(EXEEXT) > tmp-generated.c > > if diff tmp-generated.c $@ >/dev/null 2>&1; then \ > > rm -f tmp-generated.c; \ > > else \ > > mv -f tmp-generated.c $@; \ > > fi > > > > lookup_SOURCES = lookup.c $(srcdir)/generated.c > > I've got it living in $(srcdir) now, thanks. I can't see why your > version of a lazy update would speed it up though. It still runs > ./generate, and now it's running diff too, right? The version Ralf provided always runs generate but it only updates generated.c (and thereby its timestamp) when the output has changed. This means that Make no longer thinks that it needs to recompile everything that depends on generated.c (lookup in the example above). An example might be if you were to fix the indentation or add a comment to generated.c (or changed anything else that doesn't effect the output) Although I must admit I'm not sure what he means by > > [...] this shouldn't matter for read-only trees iff your > > dependencies are set up correctly [...] I'm not really sure how else you could have generated.c on the source tree and not break dist-check, but then I'm probably missing something obvious. Also, I don't want to split hairs here but isn't it less portable to use $@ in a non-suffix rule? Regards, Allan From MAILER-DAEMON Wed Feb 25 01:18:05 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LcD5o-0005LS-SP for mharc-automake@gnu.org; Wed, 25 Feb 2009 01:18:05 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcD5m-0005L2-9P for automake@gnu.org; Wed, 25 Feb 2009 01:18:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcD5k-0005Kq-EM for automake@gnu.org; Wed, 25 Feb 2009 01:18:01 -0500 Received: from [199.232.76.173] (port=59036 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcD5k-0005Kk-4R for automake@gnu.org; Wed, 25 Feb 2009 01:18:00 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:43017) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcD5j-0005oV-RV for automake@gnu.org; Wed, 25 Feb 2009 01:18:00 -0500 Received: from localhost.localdomain (xdsl-87-78-135-214.netcologne.de [87.78.135.214]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 499B540002B82; Wed, 25 Feb 2009 07:17:57 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LcD5g-0004E5-0k; Wed, 25 Feb 2009 07:17:56 +0100 Date: Wed, 25 Feb 2009 07:17:55 +0100 From: Ralf Wildenhues To: Tavian Barnes , automake@gnu.org Message-ID: <20090225061753.GA16180@ins.uni-bonn.de> Mail-Followup-To: Tavian Barnes , automake@gnu.org References: <20090223094207.GA13679@ins.uni-bonn.de> <20090224234302.GA6732@linux.vnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224234302.GA6732@linux.vnet> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: Subject: Re: Built sources and make distcheck X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 06:18:03 -0000 * Allan Caffee wrote on Wed, Feb 25, 2009 at 12:43:02AM CET: > Although I must admit I'm not sure what he means by > > > [...] this shouldn't matter for read-only trees iff your > > > dependencies are set up correctly [...] > I'm not really sure how else you could have generated.c on the source > tree and not break dist-check, but then I'm probably missing something > obvious. With distcheck, the rule for generated.c should never be invoked in the first place, as the distributed file should be up to date wrt. its prerequisites. > Also, I don't want to split hairs here but isn't it less portable to use > $@ in a non-suffix rule? No. Using $< is unportable outside of suffix rules, but $@ may be used everywhere. Cheers, Ralf From MAILER-DAEMON Wed Feb 25 18:44:10 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LcTQA-0005DO-1o for mharc-automake@gnu.org; Wed, 25 Feb 2009 18:44:10 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcTQ7-0005CJ-Dp for automake@gnu.org; Wed, 25 Feb 2009 18:44:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcTQ6-0005Bt-Lq for automake@gnu.org; Wed, 25 Feb 2009 18:44:06 -0500 Received: from [199.232.76.173] (port=55404 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcTQ6-0005Ba-B3 for automake@gnu.org; Wed, 25 Feb 2009 18:44:06 -0500 Received: from qw-out-1920.google.com ([74.125.92.148]:39768) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcTQ5-0004G9-Ty for automake@gnu.org; Wed, 25 Feb 2009 18:44:06 -0500 Received: by qw-out-1920.google.com with SMTP id 4so277853qwk.24 for ; Wed, 25 Feb 2009 15:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mail-followup-to:mime-version:content-type :content-disposition:user-agent; bh=HcEkXUC055KryWKdmx8wH5mSn2BQ4OjPk/EkZLGNMNU=; b=szKBHxCxTKNciOS/hBtwM5iKP9mxNu2kpNy3VIqfvmEXW+6+gNfp83xn8dpdXDRAhi Tw0kdnWW+Cux5ct0kYtoRN9fpu9wwxJeube0MCR1UMp7qtDSlxAgiTaXzPwIhgSsLQx/ YkIcQFQLA+mMCryHjzMJycOvh4BM/StP4PjIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; b=PEWzDXm5lxFaH3uLXMZC3c8r22cGSEX2cU1e+dD3ehh9IyBXqWJunT0mJUFZjmLBu8 EuQtt1UfP+FYz8QgNWf52+Pjc2UKsczdNEbTYbCuOmZmj+U0Kpxa0n6Qiww7IXjMZrKa OYjxLqHYpdSXi905YJuPlmh2A1Hsjrvk/57KY= Received: by 10.224.11.136 with SMTP id t8mr1290127qat.205.1235605444948; Wed, 25 Feb 2009 15:44:04 -0800 (PST) Received: from linux.vnet (pool-71-185-49-127.phlapa.fios.verizon.net [71.185.49.127]) by mx.google.com with ESMTPS id 7sm2496581qwb.51.2009.02.25.15.44.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 15:44:04 -0800 (PST) Date: Wed, 25 Feb 2009 18:44:01 -0500 From: Allan Caffee To: automake@gnu.org Message-ID: <20090225234401.GA11643@linux.vnet> Mail-Followup-To: automake@gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:44:07 -0000 What is the cleanest to way to append something to a builtin variable (e.g. MAINTAINERCLEANFILES) from an Automake "header". For example I want all of my Makefiles to delete the Makefile.in by the maintainer-clean target. The way I currently do this is: --- am/global.am --- GLOBAL_MAINTAINERCLEANFILES = Makefile.in --- Makefile.am --- include $(top_srcdir)/am/global.am MAINTAINERCLEANFILES = $(GLOBAL_MAINTAINERCLEANFILES) Which of course creates more work than it saves when it comes to deleting one file. But this has many potential uses when you consider including an Automake header that builds an RPM or doxygen documentation. Is there a cleaner, ideally non-invasive method for adding things to these builtin lists? ~Allan From MAILER-DAEMON Wed Feb 25 18:44:36 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LcTQa-0005YC-9d for mharc-automake@gnu.org; Wed, 25 Feb 2009 18:44:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcTQW-0005Uj-Ma for automake@gnu.org; Wed, 25 Feb 2009 18:44:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcTQS-0005Qf-IT for automake@gnu.org; Wed, 25 Feb 2009 18:44:28 -0500 Received: from [199.232.76.173] (port=55419 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcTQS-0005QW-6U for automake@gnu.org; Wed, 25 Feb 2009 18:44:28 -0500 Received: from qw-out-1920.google.com ([74.125.92.148]:39768) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcTQR-0004G9-K6 for automake@gnu.org; Wed, 25 Feb 2009 18:44:27 -0500 Received: by qw-out-1920.google.com with SMTP id 4so277853qwk.24 for ; Wed, 25 Feb 2009 15:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=1mh0xBNW5lJIEKQbVM5lW1TJ79psyhDD3Ex/t9l/qa0=; b=YxX+qBFDOwqURtNkRgucNNPbnjI0W2dPT1xHn3NyYRuLNH+7zzl8h28JIp9hD49eEo LPA4A18hg/hrMEvnKnmbFlcdcHUwv9vxzGeDUSMd6+LG6Yvb+LQBZY4M3d8vfDTUhgJ4 ABA+gL8lHJHYeotnDUij2MIDUA8hqlv5+6wGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=tmNpUWRaAWNRaSkogKxaH00CV1S3bb4ZEoEPrVbu81f+euezSfi5w07myAET+NKB5A O0ba4yxlP5EiziJqSBNu5ZtVvqtk1uOYnKkaU3jl1prjBYJgnoREnf62yM/reC8PdvBa XoitTPhBuzL69vS+ecILSdiC2EaiV13Jgk86g= Received: by 10.224.6.136 with SMTP id 8mr1284457qaz.234.1235605467245; Wed, 25 Feb 2009 15:44:27 -0800 (PST) Received: from linux.vnet (pool-71-185-49-127.phlapa.fios.verizon.net [71.185.49.127]) by mx.google.com with ESMTPS id 7sm3251597qwf.40.2009.02.25.15.44.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 15:44:26 -0800 (PST) Date: Wed, 25 Feb 2009 18:44:23 -0500 From: Allan Caffee To: automake@gnu.org Message-ID: <20090225234423.GA11674@linux.vnet> Mail-Followup-To: automake@gnu.org, Tavian Barnes References: <20090223094207.GA13679@ins.uni-bonn.de> <20090224234302.GA6732@linux.vnet> <20090225061753.GA16180@ins.uni-bonn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090225061753.GA16180@ins.uni-bonn.de> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Tavian Barnes Subject: Re: Built sources and make distcheck X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:44:34 -0000 On Wed, 25 Feb 2009, Ralf Wildenhues wrote: > * Allan Caffee wrote on Wed, Feb 25, 2009 at 12:43:02AM CET: > > Although I must admit I'm not sure what he means by > > > > [...] this shouldn't matter for read-only trees iff your > > > > dependencies are set up correctly [...] > > I'm not really sure how else you could have generated.c on the source > > tree and not break dist-check, but then I'm probably missing something > > obvious. > > With distcheck, the rule for generated.c should never be invoked in the > first place, as the distributed file should be up to date wrt. its > prerequisites. > > > Also, I don't want to split hairs here but isn't it less portable to use > > $@ in a non-suffix rule? > > No. Using $< is unportable outside of suffix rules, but $@ may be used > everywhere. Ah, thanks for clarifying. ~Allan From MAILER-DAEMON Wed Feb 25 19:04:18 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LcTje-0002b6-9E for mharc-automake@gnu.org; Wed, 25 Feb 2009 19:04:18 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcTjc-0002aW-HL for automake@gnu.org; Wed, 25 Feb 2009 19:04:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcTja-0002Zq-SB for automake@gnu.org; Wed, 25 Feb 2009 19:04:16 -0500 Received: from [199.232.76.173] (port=58673 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcTja-0002Zl-ND for automake@gnu.org; Wed, 25 Feb 2009 19:04:14 -0500 Received: from sovereign.computergmbh.de ([85.214.69.204]:35305) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LcTja-0006qf-75 for automake@gnu.org; Wed, 25 Feb 2009 19:04:14 -0500 Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 621E85B3D6C; Thu, 26 Feb 2009 01:04:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 60E7041E6D1B; Thu, 26 Feb 2009 01:04:09 +0100 (CET) Date: Thu, 26 Feb 2009 01:04:09 +0100 (CET) From: Jan Engelhardt Sender: jengelh@sovereign.computergmbh.de To: Allan Caffee In-Reply-To: <20090225234401.GA11643@linux.vnet> Message-ID: References: <20090225234401.GA11643@linux.vnet> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:04:16 -0000 On Thursday 2009-02-26 00:44, Allan Caffee wrote: > >What is the cleanest to way to append something to a builtin variable >(e.g. MAINTAINERCLEANFILES) from an Automake "header".[...] >Is there a cleaner, ideally non-invasive method for >adding things to these builtin lists? In one project I use -- though not a "header + main makefile" but a "main makefile + subordinates" layout --: # Makefile.am (http://tinyurl.com/dhxfwf) bin_PROGRAMS = include bar/Automakefile include foo/Automakefile # bar/Automakefile bin_PROGRAMS += bar # foo/Automakefile bin_PROGRAMS += foo that is, setting all variables ever used to "" before appending to them. From MAILER-DAEMON Thu Feb 26 08:49:22 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lcgc6-0003bh-7x for mharc-automake@gnu.org; Thu, 26 Feb 2009 08:49:22 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lcgc4-0003XF-36 for automake@gnu.org; Thu, 26 Feb 2009 08:49:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lcgc3-0003Ut-0C for automake@gnu.org; Thu, 26 Feb 2009 08:49:19 -0500 Received: from [199.232.76.173] (port=47304 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lcgc2-0003Ue-Pm for automake@gnu.org; Thu, 26 Feb 2009 08:49:18 -0500 Received: from yw-out-1718.google.com ([74.125.46.155]:62987) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lcgc1-000270-LV for automake@gnu.org; Thu, 26 Feb 2009 08:49:17 -0500 Received: by yw-out-1718.google.com with SMTP id 6so396170ywa.66 for ; Thu, 26 Feb 2009 05:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bao69GpHSxkJcS1YkyOZkw/UBfYn9ZO7e9iz6F7q+Jo=; b=AyhkXyDH7lrLkPCMKjwLQbl7Q1teC3eLg9h3CdSuMo6oD2JuRIfWwx5tEFluR9aB+9 xm1/tFyYylVhKm7z7ctxwstQuHZwgvcq7Vs3PGInooD2Ar1V1xTZW/3jTg7UETJlXoZc tC5EZhzia31DAv6ueIMSBZ84lIe+dXXK3X344= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rJzeorxYjb5C4AEYWgqeXVZ0km0UWnD1IBSg9AFT6IDTWGTiC3d4eiZWKbl0H16G/8 oww8+GqeTm1hgdMdFdNOeW7u6Tc8Lv7P7fZnIHui2qj0L4zeX42Zk5BBKxY/NiuOIdF4 TPio67QTNVbMU2CxeEjWzYOoh7dnG4YbaIQYo= MIME-Version: 1.0 Received: by 10.220.96.130 with SMTP id h2mr588549vcn.21.1235656156810; Thu, 26 Feb 2009 05:49:16 -0800 (PST) In-Reply-To: References: <20090225234401.GA11643@linux.vnet> Date: Thu, 26 Feb 2009 08:49:16 -0500 Message-ID: From: Allan Caffee To: Bob Friesenhahn , Jan Engelhardt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: automake@gnu.org Subject: Re: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:49:20 -0000 Thank you both for your speedy responses. On Wed, Feb 25, 2009 at 7:04 PM, Jan Engelhardt wrote: > In one project I use -- though not a "header + main makefile" but > a "main makefile + subordinates" layout --: > > # Makefile.am (http://tinyurl.com/dhxfwf) > bin_PROGRAMS = > include bar/Automakefile > include foo/Automakefile > > # bar/Automakefile > bin_PROGRAMS += bar > > # foo/Automakefile > bin_PROGRAMS += foo > > that is, setting all variables ever used to "" before appending to them. That is certainly one possibility. Unfortunately though that means that in the Makefile.am files you _must_ use += since Automake will error out if you assign more than one value to a variable (within the same Automake conditional block). But I was hoping for away that wouldn't require the author of Makefile.am to change their syntax. I want to "sneak" some additional files onto the clean list. Hopes and dreams aside that is much cleaner for the case I provided. I think I'll use this instead if I can't turn up a more encapsulated approach. Thanks! On Wed, Feb 25, 2009 at 7:36 PM, Bob Friesenhahn wrote: > Modern automake supports += syntax. Modern Automake does support appending. But only appending to a variable that has already been set. My understanding is that Automake handles appending in a way very similar to that shown above, using temp variables which depending on the Automake conditionals defined, may or may not be empty. This allows it to sidestep implementations of Make which don't allow +=. Perhaps we could just drop the error about appending to an undefined variable and treat it as setting the variable if not already set. I don't know how this would effect the reporting of "multiply defined" variables though. The real reason I think it would be nice to have this flexibility is for macro authors to be able to add files to be cleaned up/distributed without requiring the users to manually add anything to their setup. So assuming anything I just said was actually correct, how difficult would it be to safely allow this? ~Allan From MAILER-DAEMON Thu Feb 26 11:48:56 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LcjPr-00066R-UK for mharc-automake@gnu.org; Thu, 26 Feb 2009 11:48:55 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcjPq-00065n-LQ for automake@gnu.org; Thu, 26 Feb 2009 11:48:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcjPo-00064e-9b for automake@gnu.org; Thu, 26 Feb 2009 11:48:53 -0500 Received: from [199.232.76.173] (port=33809 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcjPo-00064Y-5t for automake@gnu.org; Thu, 26 Feb 2009 11:48:52 -0500 Received: from smtp-vbr9.xs4all.nl ([194.109.24.29]:4641) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcjPn-0008Fj-NW for automake@gnu.org; Thu, 26 Feb 2009 11:48:51 -0500 Received: from webmail.xs4all.nl (dovemail6.xs4all.nl [194.109.26.8]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id n1QGmecD064768 for ; Thu, 26 Feb 2009 17:48:48 +0100 (CET) (envelope-from jnw@xs4all.nl) Received: from 80.101.201.227 (SquirrelMail authenticated user jnw) by webmail.xs4all.nl with HTTP; Thu, 26 Feb 2009 17:48:47 +0100 (CET) Message-ID: <3929.80.101.201.227.1235666927.squirrel@webmail.xs4all.nl> Date: Thu, 26 Feb 2009 17:48:47 +0100 (CET) From: "Jeroen N. Witmond [Bahco]" To: automake@gnu.org User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 Subject: Re: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:48:55 -0000 Allan Caffee wrote: > Thank you both for your speedy responses. > > On Wed, Feb 25, 2009 at 7:04 PM, Jan Engelhardt > wrote: >> In one project I use -- though not a "header + main makefile" but >> a "main makefile + subordinates" layout --: >> >> # Makefile.am (http://tinyurl.com/dhxfwf) >> bin_PROGRAMS = >> include bar/Automakefile >> include foo/Automakefile >> >> # bar/Automakefile >> bin_PROGRAMS += bar >> >> # foo/Automakefile >> bin_PROGRAMS += foo >> >> that is, setting all variables ever used to "" before appending to them. > > That is certainly one possibility. Unfortunately though that means that > in the Makefile.am files you _must_ use += since Automake will error out > if you assign more than one value to a variable (within the same > Automake conditional block). But I was hoping for away that wouldn't > require the author of Makefile.am to change their syntax. I want to > "sneak" some additional files onto the clean list. > > Hopes and dreams aside that is much cleaner for the case I provided. I > think I'll use this instead if I can't turn up a more encapsulated > approach. Thanks! I'm not an expert on automake, but perhaps you've chosen the wrong solution to your problem: maintainer-cleaning some additional files. I would have thought target maintainer-clean-local was invented for this purpose! :) (However, I have never needed to use it.) See for instance http://www.gnu.org/software/automake/manual/html_node/Clean.html#index-maintainer_002dclean_002dlocal-751 > > > On Wed, Feb 25, 2009 at 7:36 PM, Bob Friesenhahn > wrote: >> Modern automake supports += syntax. > > Modern Automake does support appending. But only appending to a > variable that has already been set. My understanding is that Automake > handles appending in a way very similar to that shown above, using temp > variables which depending on the Automake conditionals defined, may or > may not be empty. This allows it to sidestep implementations of Make > which don't allow +=. Perhaps we could just drop the error about > appending to an undefined variable and treat it as setting the variable > if not already set. I don't know how this would effect the reporting of > "multiply defined" variables though. > > The real reason I think it would be nice to have this flexibility is for > macro authors to be able to add files to be cleaned up/distributed > without requiring the users to manually add anything to their setup. So > assuming anything I just said was actually correct, how difficult would > it be to safely allow this? > > ~Allan Jeroen. From MAILER-DAEMON Thu Feb 26 17:35:53 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lcopd-0001jK-Nh for mharc-automake@gnu.org; Thu, 26 Feb 2009 17:35:53 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lcopb-0001ga-Rc for automake@gnu.org; Thu, 26 Feb 2009 17:35:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lcopa-0001eY-9q for automake@gnu.org; Thu, 26 Feb 2009 17:35:51 -0500 Received: from [199.232.76.173] (port=42112 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lcopa-0001eR-67 for automake@gnu.org; Thu, 26 Feb 2009 17:35:50 -0500 Received: from mail-fx0-f172.google.com ([209.85.220.172]:52947) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcopZ-00043J-Pi for automake@gnu.org; Thu, 26 Feb 2009 17:35:49 -0500 Received: by fxm20 with SMTP id 20so772851fxm.42 for ; Thu, 26 Feb 2009 14:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=nxNFi/8byftLRqqpLJ3IvVLUK+yfExAGSTLIXkkNQWc=; b=DtCwkfXpmIxasBi9A4BB7FIZfJQ7y+zASEFh43gItOaMydjYbInHVHMWPvLf8bEeEi i0jWkL/aAxVKlYeebUaEEaAIVwpaMMWWbfgjSiy6SrXiDXGRIq1o2O7fWrSCZu9tG1r5 /0QokbfimWy9428soFZEzV2kykh7mzj0QXKEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=qG+KGipfg/x6fZeYFuBQPbFKsMqjTGOcXijyV5acC1IxCtTi64Se9hkAoArMqculgk 0PJRxXGnAsKK6sol0NBVopl42cYyIZM855l5VrvsKOwOx/rL4qxQfDT4wbqQDMxSU0Bb UejoplxCeKFlaI5TZdi3ls4IEggJ2Tew1uxYg= Received: by 10.223.114.79 with SMTP id d15mr2575080faq.88.1235687747618; Thu, 26 Feb 2009 14:35:47 -0800 (PST) Received: from ?192.168.0.107? (klient-catv-iv-293.selfnet.cz [213.211.57.37]) by mx.google.com with ESMTPS id 24sm394348fxm.47.2009.02.26.14.35.46 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 14:35:46 -0800 (PST) From: =?UTF-8?Q?Mat=C4=9Bj_T=C3=BD=C4=8D?= To: Ralf Wildenhues In-Reply-To: <20090224082009.GA14751@ins.uni-bonn.de> References: <670992c60902230701h46b5e1b7nf683c16788f612ef@mail.gmail.com> <20090224082009.GA14751@ins.uni-bonn.de> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Feb 2009 23:35:45 +0100 Message-Id: <1235687746.5164.0.camel@matej-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 Content-Transfer-Encoding: 8bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: GNU Automake mailing list Subject: Re: make dvi during make distcheck too annoying X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:35:52 -0000 On Tue, 2009-02-24 at 09:20 +0100, Ralf Wildenhues wrote: > Hello Matěj, > > * Matěj Týč wrote on Mon, Feb 23, 2009 at 04:01:34PM CET: > > The problem is that running 'make distcheck' results in error since > > the EPS images that should be there aren't there and 'make distcheck' > > tries to run 'make dvi' everywhere. > > I would like to run 'make pdf' instead or at least to disable building DVI. > > You can overwrite the target in order to disable it: > dvi: Thank you very much, Ralf, that worked! From MAILER-DAEMON Fri Feb 27 19:25:37 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdD1M-0005iA-SK for mharc-automake@gnu.org; Fri, 27 Feb 2009 19:25:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdD1L-0005hn-N3 for automake@gnu.org; Fri, 27 Feb 2009 19:25:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdD1L-0005hQ-2M for automake@gnu.org; Fri, 27 Feb 2009 19:25:35 -0500 Received: from [199.232.76.173] (port=51965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdD1K-0005hL-Qi for automake@gnu.org; Fri, 27 Feb 2009 19:25:34 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:5989) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdD1K-0003ZI-Fc for automake@gnu.org; Fri, 27 Feb 2009 19:25:34 -0500 Received: by qw-out-1920.google.com with SMTP id 4so1305601qwk.24 for ; Fri, 27 Feb 2009 16:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=hBDoejNA7NQZ2HkFAx85IlO3Pa/G/cdNNdWuuYsnSJg=; b=ZDM7zdbD0FM+HkpL71uupUpOJcTtUYZ8Bp2/pNz9gyvmZECI6gwK/1Xe20eY8GGNFn s/jbfKfB8WKzcBVQnbs/N3bwTPzUTfnN7Y1jAkcD/3+SVH1C+w6BGnM4YV1cXOnjw5MS x838JPx7uBAAOKGpp1Z9BN6gYe6S+6oMesMbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=Zm67hP5MF3PQRV4JRw7k1NrI3Znw69JCJq9at/Av4h5f+JEIMpFs/aPAOg616Yncu8 J8M6N0fKkOCOAXnPtYYmctap4HeQfZOKwY40Uh0Y3jYGmvHNcJh5GvP8BbOuoKGJdgqL 6Cb4ZIcnuWM2/c0scdv6VzT6Ga0rPuPDTwOfs= Received: by 10.224.29.10 with SMTP id o10mr5118000qac.95.1235780733108; Fri, 27 Feb 2009 16:25:33 -0800 (PST) Received: from linux.vnet (pool-71-185-49-127.phlapa.fios.verizon.net [71.185.49.127]) by mx.google.com with ESMTPS id 2sm526296qwi.38.2009.02.27.16.25.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 16:25:32 -0800 (PST) Date: Fri, 27 Feb 2009 19:25:29 -0500 From: Allan Caffee To: "Jeroen N. Witmond [Bahco]" Message-ID: <20090228002529.GA6398@linux.vnet> Mail-Followup-To: "Jeroen N. Witmond [Bahco]" , automake@gnu.org References: <3929.80.101.201.227.1235666927.squirrel@webmail.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3929.80.101.201.227.1235666927.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: automake@gnu.org Subject: Re: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:25:36 -0000 On Thu, 26 Feb 2009, Jeroen N. Witmond [Bahco] wrote: > I'm not an expert on automake, but perhaps you've chosen the wrong > solution to your problem: maintainer-cleaning some additional files. I > would have thought target maintainer-clean-local was invented for this > purpose! :) (However, I have never needed to use it.) > > See for instance > http://www.gnu.org/software/automake/manual/html_node/Clean.html#index-maintainer_002dclean_002dlocal-751 Well yes. The maintainer-clean-local hook would allow an included snippet to delete some files but that would prevent the main Makefile.am from being able to define a maintainer-clean-local target. I was hoping for something that, if used in an Automake snippet provided by a third party, would not interfere with the developer at all. For example a macro in the Autoconf archive that generates Automake code. Unfortunatly I don't think anything quite like this exists in Automake atm. :( How difficult would it be to allow third parties to hook into special Automake targets like the *-local targets? For example a macro could provide a rule like: maintainer-clean-macro-hook: -rm -rf $(DOXYGEN_HTML_DIR) And Automake would graciously add that (and any other rules with the same target name) as prerequisites to maintainer-clean. What do you guys think? ~Allan From MAILER-DAEMON Sat Feb 28 05:16:26 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdMF8-00015s-CC for mharc-automake@gnu.org; Sat, 28 Feb 2009 05:16:26 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdMF6-00015L-C4 for automake@gnu.org; Sat, 28 Feb 2009 05:16:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdMF5-00014r-LS for automake@gnu.org; Sat, 28 Feb 2009 05:16:23 -0500 Received: from [199.232.76.173] (port=36496 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdMF5-00014h-HU for automake@gnu.org; Sat, 28 Feb 2009 05:16:23 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:59213) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdMF5-0006NF-4N for automake@gnu.org; Sat, 28 Feb 2009 05:16:23 -0500 Received: from localhost.localdomain (xdsl-87-78-140-54.netcologne.de [87.78.140.54]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 765F3400016DF; Sat, 28 Feb 2009 11:16:20 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LdMF0-0000zL-Hn; Sat, 28 Feb 2009 11:16:18 +0100 Date: Sat, 28 Feb 2009 11:16:18 +0100 From: Ralf Wildenhues To: Allan Caffee Message-ID: <20090228101617.GA3648@ins.uni-bonn.de> Mail-Followup-To: Allan Caffee , Bob Friesenhahn , Jan Engelhardt , automake@gnu.org References: <20090225234401.GA11643@linux.vnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 10:16:24 -0000 Hello, * Allan Caffee wrote on Thu, Feb 26, 2009 at 02:49:16PM CET: > That is certainly one possibility. Unfortunately though that means that > in the Makefile.am files you _must_ use += since Automake will error out > if you assign more than one value to a variable (within the same > Automake conditional block). Which is a good thing: two assignments are a potential error, and will often result in something undesirable. > But I was hoping for away that wouldn't > require the author of Makefile.am to change their syntax. I want to > "sneak" some additional files onto the clean list. This attitude can be fixed by changing the default approach: always write your Makefile.am files or snippets so they only append to variables. :-) That way, the only person needing to adjust is the one supplying the outer file (or you first include a snippet that initializes all needed variables to empty). > Modern Automake does support appending. But only appending to a > variable that has already been set. Yes. This is done primarily to be able to diagnose typos, e.g., foolish = foo1ish += bar (no pun intended, BTW), but also to provide more deterministic semantics in the presence of conditionals (I don't remember the details). Is it worth the hassle? It's certainly a trade-off: - more work due to required initializations of all variables, - OTOH typos in variables can have rather subtle implications, esp. if those variables are of the "magic automake" kind. I suppose a more sophisticated implementation would allow to let automake work in a mode that wouldn't error out on += for uninitialized variables (e.g., with a command line switch -Wno-var-append or so). > My understanding is that Automake > handles appending in a way very similar to that shown above, using temp > variables which depending on the Automake conditionals defined, may or > may not be empty. Yes, possibly. > This allows it to sidestep implementations of Make > which don't allow +=. Perhaps we could just drop the error about > appending to an undefined variable and treat it as setting the variable > if not already set. I don't know how this would effect the reporting of > "multiply defined" variables though. See above. > The real reason I think it would be nice to have this flexibility is for > macro authors to be able to add files to be cleaned up/distributed > without requiring the users to manually add anything to their setup. So > assuming anything I just said was actually correct, how difficult would > it be to safely allow this? I think thinking through the special cases that can come up with conditionals would be most of the work. If you want to contribute a patch, please read the HACKING file in the git tree. Cheers, Ralf From MAILER-DAEMON Sat Feb 28 09:14:36 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdPxc-00032n-CF for mharc-automake@gnu.org; Sat, 28 Feb 2009 09:14:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdPxa-00031m-IL for automake@gnu.org; Sat, 28 Feb 2009 09:14:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdPxZ-000312-Jl for automake@gnu.org; Sat, 28 Feb 2009 09:14:33 -0500 Received: from [199.232.76.173] (port=56543 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdPxZ-00030v-DT for automake@gnu.org; Sat, 28 Feb 2009 09:14:33 -0500 Received: from nagini.codelibre.net ([80.68.93.164]:38612) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdPxZ-0002vI-1K for automake@gnu.org; Sat, 28 Feb 2009 09:14:33 -0500 Received: by nagini.codelibre.net (Postfix, from userid 107) id 38DA318280; Sat, 28 Feb 2009 14:14:32 +0000 (GMT) Received: from hardknott (78-105-115-105.zone3.bethere.co.uk [78.105.115.105]) by nagini.codelibre.net (Postfix) with ESMTPSA id 87D671819D for ; Sat, 28 Feb 2009 14:14:30 +0000 (GMT) Received: by hardknott (Postfix, from userid 1000) id 319FC120B0; Sat, 28 Feb 2009 14:14:27 +0000 (GMT) Date: Sat, 28 Feb 2009 14:14:27 +0000 From: Roger Leigh To: automake@gnu.org Message-ID: <20090228141426.GD4349@codelibre.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9dgjiU4MmWPVapMU" Content-Disposition: inline X-GPG-Key: 0x25BFB848 X-Debian: testing/unstable X-OS-Uptime: 09:20:20 up 1 min, 1 user, load average: 0.64, 0.29, 0.11 User-Agent: Mutt/1.5.18 (2008-05-17) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.7 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: make distcheck fail due to unset DESTDIR X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:14:34 -0000 --9dgjiU4MmWPVapMU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks, In a Makefile.am, I have the following: ------------------ if BUILD_DEBVERSION pg_server_lib_LTLIBRARIES =3D \ debversion.la debversion_la_SOURCES =3D \ debversion.cc debversion_la_CXXFLAGS =3D -I$(pg_server_includedir) debversion_la_LDFLAGS =3D -module -avoid-version $(APT_PKG_LIBS) pg_contrib_DATA =3D \ debversion.sql \ uninstall_debversion.sql endif debversion.sql: debversion.sql.in sed 's,MODULE_PATHNAME,$$libdir/$*,g' $< >$@ ---------------- However, "make distcheck" fails, with: make[3]: Entering directory `/home/rleigh/sbuild/sbuild-0.58.0/_build/db' make[3]: Nothing to be done for `install-exec-am'. test -z "/usr/share/postgresql/8.3/contrib" || /bin/mkdir -p "/usr/share/po= stgresql/8.3/contrib" /usr/bin/install -c -m 644 'debversion.sql' '/usr/share/postgresql/8.3/con= trib/debversion.sql' /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3/con= trib/debversion.sql': Permission denied /usr/bin/install -c -m 644 '../../db/uninstall_debversion.sql' '/usr/share= /postgresql/8.3/contrib/uninstall_debversion.sql' /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3/con= trib/uninstall_debversion.sql': Permission denied The rule itself looks OK: install-pg_contribDATA: $(pg_contrib_DATA) @$(NORMAL_INSTALL) test -z "$(pg_contribdir)" || $(MKDIR_P) "$(DESTDIR)$(pg_contribdir= )" @list=3D'$(pg_contrib_DATA)'; for p in $$list; do \ if test -f "$$p"; then d=3D; else d=3D"$(srcdir)/"; fi; \ f=3D$(am__strip_dir) \ echo " $(pg_contribDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(pg_contrib= dir)/$$f'"; \ $(pg_contribDATA_INSTALL) "$$d$$p" "$(DESTDIR)$(pg_contribdir)/$$= f"; \ done It contains DESTDIR, and DESTDIR is set in the top-level Makefile in the distcheck rule. So I'm not sure where the cause of this failure lies-- I can't see anything obvious in the Makefile.am. I tried removing the automake conditional in case that screwed things up subtly, but it makes no difference. I'm using automake-1.10.1 on Debian GNU/Linux. The full source is at: http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz (db/Makefile.am is the Makefile in question.) Many thanks, Roger --=20 .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. --9dgjiU4MmWPVapMU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmpRsIACgkQVcFcaSW/uEhLJQCg3Jl0uqEFkhXK++xgVP3JRa48 T24AnipErSZzzBJGaT3B+Gz9gsavi5Pw =3qCc -----END PGP SIGNATURE----- --9dgjiU4MmWPVapMU-- From MAILER-DAEMON Sat Feb 28 09:38:53 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdQL6-0002qb-V4 for mharc-automake@gnu.org; Sat, 28 Feb 2009 09:38:52 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdQL4-0002oh-R4 for automake@gnu.org; Sat, 28 Feb 2009 09:38:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdQL0-0002kw-KE for automake@gnu.org; Sat, 28 Feb 2009 09:38:49 -0500 Received: from [199.232.76.173] (port=33974 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdQL0-0002km-GF for automake@gnu.org; Sat, 28 Feb 2009 09:38:46 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:47186) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdQL0-0006zs-0w for automake@gnu.org; Sat, 28 Feb 2009 09:38:46 -0500 Received: from localhost.localdomain (xdsl-87-78-140-54.netcologne.de [87.78.140.54]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 1080C400028EB; Sat, 28 Feb 2009 15:38:45 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LdQKw-0005t0-PA; Sat, 28 Feb 2009 15:38:42 +0100 Date: Sat, 28 Feb 2009 15:38:42 +0100 From: Ralf Wildenhues To: Roger Leigh Message-ID: <20090228143842.GB22526@ins.uni-bonn.de> Mail-Followup-To: Roger Leigh , automake@gnu.org References: <20090228141426.GD4349@codelibre.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228141426.GD4349@codelibre.net> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: make distcheck fail due to unset DESTDIR X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:38:51 -0000 * Roger Leigh wrote on Sat, Feb 28, 2009 at 03:14:27PM CET: > pg_contrib_DATA = \ > debversion.sql \ > uninstall_debversion.sql > However, "make distcheck" fails, with: > > make[3]: Entering directory `/home/rleigh/sbuild/sbuild-0.58.0/_build/db' > make[3]: Nothing to be done for `install-exec-am'. > test -z "/usr/share/postgresql/8.3/contrib" || /bin/mkdir -p "/usr/share/postgresql/8.3/contrib" > /usr/bin/install -c -m 644 'debversion.sql' '/usr/share/postgresql/8.3/contrib/debversion.sql' > /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3/contrib/debversion.sql': Permission denied > /usr/bin/install -c -m 644 '../../db/uninstall_debversion.sql' '/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql' > /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql': Permission denied > The full source is at: > http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz The problem is likely this code in configure.ac: AC_MSG_CHECKING([for PostgreSQL architecture-independent support files directory]) pg_server_sharedir=`"$PG_CONFIG" --sharedir` AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQL architecture-independent support files directory])], [pg_server_sharedir="${withval}"]) AC_MSG_RESULT([$pg_server_sharedir]) AC_SUBST([pg_server_sharedir]) pg_contribdir="$pg_server_sharedir/contrib" AC_SUBST([pg_contribdir]) Why? Apart from a DESTDIR install, distcheck also tries to configure and install the tree below some specific --prefix, and tries to ensure that your package installs all files below $prefix. This is a requirement from the GNU Coding Standards. See here for more information: One way to fix your code would be to check for whether the user has overridden $prefix, $datarootdir, or $datadir, and in that case, let pg_server_sharedir depend on the latter (the defaults for these variables are NONE, '${prefix}/share', and '${datarootdir}', respectively, with recent Autoconf versions). Another way to let the distcheck pass (but still allow to annoy your users ;-) is to add an appropriate --with-pg-server-sharedir to the make macro DISTCHECK_CONFIGURE_FLAGS. BTW, in above code, there are a couple of trivial issues: this AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQL architecture-independent support files directory])], [pg_server_sharedir="${withval}"]) should likely be something like: AC_ARG_ENABLE([pg-server-sharedir], [AS_HELP_STRING([--enable-pg-server-sharedir], [PostgreSQL architecture-independent support files directory])], [pg_server_sharedir="${enableval}"]) no? Hope that helps. Cheers, Ralf From MAILER-DAEMON Sat Feb 28 12:10:27 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdShn-0000FU-MH for mharc-automake@gnu.org; Sat, 28 Feb 2009 12:10:27 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdShl-0000Ef-Dx for automake@gnu.org; Sat, 28 Feb 2009 12:10:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdShi-0000Do-MO for automake@gnu.org; Sat, 28 Feb 2009 12:10:25 -0500 Received: from [199.232.76.173] (port=43308 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdShi-0000Dl-Ji for automake@gnu.org; Sat, 28 Feb 2009 12:10:22 -0500 Received: from nagini.codelibre.net ([80.68.93.164]:51577) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdShh-0000zW-Vk for automake@gnu.org; Sat, 28 Feb 2009 12:10:22 -0500 Received: by nagini.codelibre.net (Postfix, from userid 107) id 6E6A018280; Sat, 28 Feb 2009 17:10:20 +0000 (GMT) Received: from hardknott (78-105-115-105.zone3.bethere.co.uk [78.105.115.105]) by nagini.codelibre.net (Postfix) with ESMTPSA id 7BD821819D for ; Sat, 28 Feb 2009 17:10:17 +0000 (GMT) Received: by hardknott (Postfix, from userid 1000) id 61B04120B0; Sat, 28 Feb 2009 17:10:11 +0000 (GMT) Date: Sat, 28 Feb 2009 17:10:11 +0000 From: Roger Leigh To: automake@gnu.org Message-ID: <20090228171010.GE4349@codelibre.net> References: <20090228141426.GD4349@codelibre.net> <20090228143842.GB22526@ins.uni-bonn.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="so9zsI5B81VjUb/o" Content-Disposition: inline In-Reply-To: <20090228143842.GB22526@ins.uni-bonn.de> X-GPG-Key: 0x25BFB848 X-Debian: testing/unstable X-OS-Uptime: 09:20:20 up 1 min, 1 user, load average: 0.64, 0.29, 0.11 User-Agent: Mutt/1.5.18 (2008-05-17) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.7 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: make distcheck fail due to unset DESTDIR X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 17:10:25 -0000 --so9zsI5B81VjUb/o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 28, 2009 at 03:38:42PM +0100, Ralf Wildenhues wrote: > * Roger Leigh wrote on Sat, Feb 28, 2009 at 03:14:27PM CET: > > pg_contrib_DATA =3D \ > > debversion.sql \ > > uninstall_debversion.sql >=20 > > However, "make distcheck" fails, with: > >=20 > > make[3]: Entering directory `/home/rleigh/sbuild/sbuild-0.58.0/_build/d= b' > > make[3]: Nothing to be done for `install-exec-am'. > > test -z "/usr/share/postgresql/8.3/contrib" || /bin/mkdir -p "/usr/shar= e/postgresql/8.3/contrib" > > /usr/bin/install -c -m 644 'debversion.sql' '/usr/share/postgresql/8.3= /contrib/debversion.sql' > > /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3= /contrib/debversion.sql': Permission denied > > /usr/bin/install -c -m 644 '../../db/uninstall_debversion.sql' '/usr/s= hare/postgresql/8.3/contrib/uninstall_debversion.sql' > > /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3= /contrib/uninstall_debversion.sql': Permission denied >=20 > > The full source is at: > > http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz >=20 > The problem is likely this code in configure.ac: > AC_MSG_CHECKING([for PostgreSQL architecture-independent support files = directory]) > pg_server_sharedir=3D`"$PG_CONFIG" --sharedir` > AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQ= L architecture-independent support files directory])], > [pg_server_sharedir=3D"${withval}"]) > AC_MSG_RESULT([$pg_server_sharedir]) > AC_SUBST([pg_server_sharedir]) >=20 > pg_contribdir=3D"$pg_server_sharedir/contrib" > AC_SUBST([pg_contribdir]) >=20 > Why? Apart from a DESTDIR install, distcheck also tries to configure > and install the tree below some specific --prefix, and tries to ensure > that your package installs all files below $prefix. This is a > requirement from the GNU Coding Standards. See here for more > information: Thanks. I remembered after I sent the mail that I'd actually come across this limitation before, and I think brought it up on the list. While I do agree that the GNU coding standards are correct in insisting that all files are installed under $prefix, I do think that there are valid situations where this ideal scenario does not make sense. For example: gutenprint provides CUPS printer drivers (backends), which *must* be installed under $(cups-config --serverbin) [/usr/lib/cups on my system]. Installing under /prefix would be possible, but would be completely useless (the CUPS server looks in one location only for available backends). Currently, we do allow the user to override the extra-prefix default location, so user installation is possible, but not the default. In this case, we are installing a PostgreSQL database extension, which really needs the loadable modules installing in $(pg_config --pkglibdir) [/usr/lib/postgresql/8.3/lib] on my system. This is by default the only path searched for extensions, though it is possible to add alternative locations. I guess my point here is that for some packages, user installation is simply not possible (at least for some components of the package). For others, it is possible, but not ideal. I'm not sure exactly the best way to default things in the configure script in the latter case. Defaulting to strict GNU coding standards correctness isn't going to be what most people would want. Would it be possible to use *both* --prefix and $(DESTDIR) when testing "make install" within "make distcheck"? This would provide several advantages: 1) The installation won't just fail if it attempts to install into a location outside $prefix. If the location *had* been writable, it would still have succeeded had I run distcheck as root, for example, so *success doesn't guarantee a non-buggy package*. The uninstall check could even have removed files from the system AFAICT. 2) You can now check $prefix inside the DESTDIR, and also look at files installed outside $prefix but which are present in the DESTDIR and report these as buggy to the user and error out, which would help bring buggy Makefile.ams to the developer's attention. This isn't currently done. It would also allow one to add an automake option to not treat these files outside the prefix as errors. This would both make distcheck both more robust, and more flexible. While for all but a few packages installing outside $prefix is completely wrong, I think that it would be nice it automake had the flexibility to allow it if given the option, but obviously not the default! > One way to fix your code would be to check for whether the user has > overridden $prefix, $datarootdir, or $datadir, and in that case, let > pg_server_sharedir depend on the latter (the defaults for these > variables are NONE, '${prefix}/share', and '${datarootdir}', > respectively, with recent Autoconf versions). Another way to let > the distcheck pass (but still allow to annoy your users ;-) > is to add an appropriate --with-pg-server-sharedir to the make macro > DISTCHECK_CONFIGURE_FLAGS. The latter choice would make sense. We already allow the user to override all these settings, so if the do want them under $prefix, it's possible. > BTW, in above code, there are a couple of trivial issues: this > AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQ= L architecture-independent support files directory])], > [pg_server_sharedir=3D"${withval}"]) >=20 > should likely be something like: > AC_ARG_ENABLE([pg-server-sharedir], OK, thanks. Is enable appropriate here rather than wide? It's slightly ambiguous as to whether this is working with external software or a feature to enable (since it's sort of both). Many thanks, Roger --=20 .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. --so9zsI5B81VjUb/o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmpb/IACgkQVcFcaSW/uEjMbQCdHbZ6B7Ryontvon6axFT9m9yZ YWEAnRypTq/VTx+96uZ2yLUJMtt3bazh =gYNO -----END PGP SIGNATURE----- --so9zsI5B81VjUb/o-- From MAILER-DAEMON Sat Feb 28 12:34:12 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdT4l-0001SL-T7 for mharc-automake@gnu.org; Sat, 28 Feb 2009 12:34:11 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdT4k-0001Ps-DI for automake@gnu.org; Sat, 28 Feb 2009 12:34:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdT4j-0001Ov-R2 for automake@gnu.org; Sat, 28 Feb 2009 12:34:09 -0500 Received: from [199.232.76.173] (port=58926 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdT4j-0001OZ-IW for automake@gnu.org; Sat, 28 Feb 2009 12:34:09 -0500 Received: from merkur.ins.uni-bonn.de ([131.220.223.13]:41841) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdT4i-00071L-UP for automake@gnu.org; Sat, 28 Feb 2009 12:34:09 -0500 Received: from localhost.localdomain (xdsl-87-78-140-54.netcologne.de [87.78.140.54]) by merkur.ins.uni-bonn.de (Postfix) with ESMTP id 91B3240002D47; Sat, 28 Feb 2009 18:34:07 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1LdT4h-000623-HI; Sat, 28 Feb 2009 18:34:07 +0100 Date: Sat, 28 Feb 2009 18:34:07 +0100 From: Ralf Wildenhues To: Roger Leigh Message-ID: <20090228173406.GH22717@ins.uni-bonn.de> Mail-Followup-To: Roger Leigh , automake@gnu.org References: <20090228141426.GD4349@codelibre.net> <20090228143842.GB22526@ins.uni-bonn.de> <20090228171010.GE4349@codelibre.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228171010.GE4349@codelibre.net> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: make distcheck fail due to unset DESTDIR X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 17:34:10 -0000 * Roger Leigh wrote on Sat, Feb 28, 2009 at 06:10:11PM CET: > On Sat, Feb 28, 2009 at 03:38:42PM +0100, Ralf Wildenhues wrote: > > Why? Apart from a DESTDIR install, distcheck also tries to configure > > and install the tree below some specific --prefix, and tries to ensure > > that your package installs all files below $prefix. This is a > > requirement from the GNU Coding Standards. See here for more > > information: > While I do agree that the GNU coding standards are correct in insisting > that all files are installed under $prefix, I do think that there are > valid situations where this ideal scenario does not make sense. And I agree. But I think that we can have both! > For example: gutenprint provides CUPS printer drivers (backends), which > *must* be installed under $(cups-config --serverbin) [/usr/lib/cups on > my system]. Installing under /prefix would be possible, but would be > completely useless (the CUPS server looks in one location only for > available backends). Currently, we do allow the user to override the > extra-prefix default location, so user installation is possible, but > not the default. OK. > I guess my point here is that for some packages, user installation is > simply not possible (at least for some components of the package). Well, one autotool principle is "the user may be smarter than the package developer". While on all setups you're aware of, user installation isn't possible, some user may be smart enough to hack up her system to allow for it. Not limiting that user is a worthy goal. > For others, it is possible, but not ideal. I'm not sure exactly the > best way to default things in the configure script in the latter case. > Defaulting to strict GNU coding standards correctness isn't going to > be what most people would want. Well, you don't need the *default* to be using $datadir. At least not when neither --prefix, --datarootdir, nor --datadir have been used. > Would it be possible to use *both* --prefix and $(DESTDIR) when > testing "make install" within "make distcheck"? This kind of testing is *also* done during the course of distcheck. > 1) The installation won't just fail if it attempts to install into > a location outside $prefix. If the location *had* been writable, > it would still have succeeded had I run distcheck as root, for > example, so *success doesn't guarantee a non-buggy package*. > The uninstall check could even have removed files from the > system AFAICT. Hmm, a couple of notes: first, I for one wouldn't ever run distcheck as root unless the package passed distcheck as unprivileged user and I had rather closely inspected it. Second, the part of distcheck that tests a DESTDIR install does make the $prefix non-writable, so it should catch such a buggy package, at least when distcheck is run as an unprivileged user. > 2) You can now check $prefix inside the DESTDIR, and also look at > files installed outside $prefix but which are present in the > DESTDIR and report these as buggy to the user and error out, > which would help bring buggy Makefile.ams to the developer's > attention. This isn't currently done. It would also allow one > to add an automake option to not treat these files outside the > prefix as errors. Yes, I suppose we could do this. I can only guess that it hasn't been done before because it may not be so uncommon to install outside of $prefix (e.g. /etc). > This would both make distcheck both more robust, and more flexible. > While for all but a few packages installing outside $prefix is > completely wrong, I think that it would be nice it automake > had the flexibility to allow it if given the option, but obviously > not the default! If you want to submit a patch, be sure to read the HACKING file in the git repo of Automake. > > BTW, in above code, there are a couple of trivial issues: this > > AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQL architecture-independent support files directory])], > > [pg_server_sharedir="${withval}"]) > > > > should likely be something like: > > AC_ARG_ENABLE([pg-server-sharedir], > > OK, thanks. Is enable appropriate here rather than wide? It's > slightly ambiguous as to whether this is working with external > software or a feature to enable (since it's sort of both). Oh. I wasn't aware of that. Again, the GCS lists the criteria: but some choices just are sort of both, and in that case, it's good to stick to what you prefer or other packages do in the same case, I guess. Cheers, Ralf From MAILER-DAEMON Sat Feb 28 18:38:49 2009 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdYld-0002lr-8f for mharc-automake@gnu.org; Sat, 28 Feb 2009 18:38:49 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdYlb-0002if-3R for automake@gnu.org; Sat, 28 Feb 2009 18:38:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdYla-0002hQ-G4 for automake@gnu.org; Sat, 28 Feb 2009 18:38:46 -0500 Received: from [199.232.76.173] (port=41844 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdYla-0002hI-A1 for automake@gnu.org; Sat, 28 Feb 2009 18:38:46 -0500 Received: from sovereign.computergmbh.de ([85.214.69.204]:54092) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LdYlZ-0006ww-TU for automake@gnu.org; Sat, 28 Feb 2009 18:38:46 -0500 Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 67B68C8D33; Sun, 1 Mar 2009 00:38:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 6203F403C9FA; Sun, 1 Mar 2009 00:38:41 +0100 (CET) Date: Sun, 1 Mar 2009 00:38:41 +0100 (CET) From: Jan Engelhardt Sender: jengelh@sovereign.computergmbh.de To: Ralf Wildenhues In-Reply-To: <20090228101617.GA3648@ins.uni-bonn.de> Message-ID: References: <20090225234401.GA11643@linux.vnet> <20090228101617.GA3648@ins.uni-bonn.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: automake@gnu.org Subject: Re: Appending to builtin Automake variables from an included file X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for automake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 23:38:47 -0000 On Saturday 2009-02-28 11:16, Ralf Wildenhues wrote: >> Modern Automake does support appending. But only appending to a >> variable that has already been set. > >Yes. This is done primarily to be able to diagnose typos, e.g., > foolish = > foo1ish += bar >[...] >Is it worth the hassle? It's certainly a trade-off: >- more work due to required initializations of all variables, >- OTOH typos in variables can have rather subtle implications, > esp. if those variables are of the "magic automake" kind. - "+=" could append to variables implicitly defined by make (the horror!). Though this does not happen with automake, users could walk into a trip when they have to write a manual Makefile (e.g. Makefile.in) without the use of Automake.