From unknown Fri Aug 15 02:02:21 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#9506 <9506@debbugs.gnu.org> To: bug#9506 <9506@debbugs.gnu.org> Subject: Status: makeinfo in VPATH builds fails Reply-To: bug#9506 <9506@debbugs.gnu.org> Date: Fri, 15 Aug 2025 09:02:21 +0000 retitle 9506 makeinfo in VPATH builds fails reassign 9506 automake submitter 9506 Sebastian Freundt severity 9506 normal tag 9506 wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 12:19:27 2011 Received: (at submit) by debbugs.gnu.org; 14 Sep 2011 16:19:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R3sBJ-000271-WF for submit@debbugs.gnu.org; Wed, 14 Sep 2011 12:19:27 -0400 Received: from mx01.ffm1.treml-sturm.net ([217.68.2.100]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R3qzb-0004sF-GS for submit@debbugs.gnu.org; Wed, 14 Sep 2011 11:03:20 -0400 Received: from localhost (localhost [127.0.0.1]) by mx01.ffm1.treml-sturm.net (Postfix) with ESMTP id B298914925 for ; Wed, 14 Sep 2011 16:58:40 +0200 (CEST) Received: from wiesinginvestments.com (p5098db61.dip0.t-ipconnect.de [80.152.219.97]) by mx01.ffm1.treml-sturm.net (Postfix) with ESMTP id 7B6D814921 for ; Wed, 14 Sep 2011 16:58:30 +0200 (CEST) Received: from berlin.ga-group.nl ([192.168.1.26]) by wiesinginvestments.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 16:58:30 +0200 From: Sebastian Freundt To: submit@debbugs.gnu.org Subject: makeinfo in VPATH builds fails X-Gpg-Key-Id: 0x82C9390E X-Fingerprint: 6CB0 D61E 23A4 275C C2CF A161 94C9 A1AC 82C9 390E X-Face: #HUK$+njZzfa\Y7-C?%}`0I+_5(GhEOmLsy4}, ^7)im*%||Zh=:FnuCpe1gt+p:Omkx{a}BSf}DSn4], m9[bw5*gsG$Xx<-V"(L0?M8*&H\hh^^cd7F~B=/KkLl\mNdk\_}HrPG}=cnAwt=\tWF6J X-Discordian-Date: Boomtime, 38th of Bureaucracy, yold 3177. Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWLYy//y8qfMzN/UVL/ l5eamX/LmWbRZmLMmZjg3qv+zZf7/vr727f6AAACVklEQVR42o3UMWvbQBQA4CPG8dDJNBRXXUwy ZHURoS1d2iJkVVNIcNI0i8GXp6unEMMpY0uU68WdAmmRm8lwpOJtpgSi5s/1To6lS2mhN+rTu/f0 7p3I7T8W+T84n/wFrm9Od3rbvS9/Qr47IoSsdmp7l/dhs8GXNKy2yf49eNjmlMbAedRe27dgtrWc hOh5gD6QlxbcLEGi0CzlR3ULfq7LBOfLg5EFW8vBGLHpmBAY7Jcw67AgRJwaQD96WsEykxqcu72e V1vFwEJcJBlvlHC9U4Hy/O0nZUQEML7LoWFQbdUHoDhtFmUFooJ0wIFJXW9z2kQlBuVWX3e5Th/x 4dTECPMhBcw+fjvmMnxsKhAxj2olqFqDy8kpMMziBnCygAv1pjFiB+8EhD4A9OsLWMFXPn0rpRDD 6FPv2WEZ0Qp+cJqhSnzaTc86hCzKXQmvYmo6BbQLIiJl8gtsFaAE9UEAWVtEnGvQHcGpHypG4ai+ gNzJ4uKc4LVDBYselC1xfA1OUwXDbOgFUdX22SOe6N4qCtFQBaPqaPPWcVJ0HCFUAangVpjeGvCp 8l1rSiRLx8X5ZYkSNQvSD5kBDzMp+xsWtBimeBXHMUgxsEd0j71PEaNuvD4U/RcW/BLj1CTvxuPT gT3tjpCmrGBFfofOfShmQemvgG374pxJJuf1ik3XjriW0ow7KhSHdStCP5fziKA/v1AWCJMdZd+1 LmcuWRKm8gwnKF0Lct1DT7+sV/rZdasfwGUOBhSmIjpyXesHkAt2dznEQc/ds5LrHk4LODmY9OY5 fgNaH4km3mN9MwAAAABJRU5ErkJggg== Date: Wed, 14 Sep 2011 14:58:28 +0000 Message-ID: <81d3f35fxn.fsf@berlin.ga-group.nl> User-Agent: Gnus/5.110014 (No Gnus v0.14) SXEmacs/22.1.14 (linux) MIME-Version: 1.0 Content-Type: text/plain X-OriginalArrivalTime: 14 Sep 2011 14:58:30.0473 (UTC) FILETIME=[C41A1B90:01CC72EE] X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 14 Sep 2011 12:19:25 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Package: automake Version: 1.11a VPATH build of a project using makeinfo fails if $(srcdir) isn't writable. freundt@plutos:~/devel_freundt/datetools/=build> make /home/freundt/devel/datetools/git-version-gen .version >/dev/null make all-recursive make[1]: Entering directory `/home/guest/devel_freundt/datetools/=build' Making all in info make[2]: Entering directory `/home/guest/devel_freundt/datetools/=build/info' restore=: && backupdir=".am$$" && \ am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd /home/freundt/devel/datetools/info && \ rm -rf $backupdir && mkdir $backupdir && \ if (/bin/sh /home/freundt/devel/datetools/missing --run makeinfo --version) >/dev/null 2>&1; then \ for f in /home/freundt/devel/datetools/info/datetools.info /home/freundt/devel/datetools/info/datetools.info-[0-9] /home/freundt/devel/datetools/info/datetools.info-[0-9][0-9] /home/freundt/devel/datetools/info/datetools.i[0-9] /home/freundt/devel/datetools/info/datetools.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ cd "$am__cwd"; \ if /bin/sh /home/freundt/devel/datetools/missing --run makeinfo -I /home/freundt/devel/datetools/info \ -o /home/freundt/devel/datetools/info/datetools.info /home/freundt/devel/datetools/info/datetools.texi; \ then \ rc=0; \ CDPATH="${ZSH_VERSION+.}:" && cd /home/freundt/devel/datetools/info; \ else \ rc=$?; \ CDPATH="${ZSH_VERSION+.}:" && cd /home/freundt/devel/datetools/info && \ $restore $backupdir/* `echo ".//home/freundt/devel/datetools/info/datetools.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc mkdir: cannot create directory `.am20510': Permission denied /home/freundt/devel/datetools/info/datetools.info: Permission denied make[2]: *** [/home/freundt/devel/datetools/info/datetools.info] Error 1 make[2]: Leaving directory `/home/guest/devel_freundt/datetools/=build/info' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/guest/devel_freundt/datetools/=build' make: *** [all] Error 2 Expected behaviour: freundt@plutos:~/devel_freundt/datetools/=build> cd info freundt@plutos:~/devel_freundt/datetools/=build/info> makeinfo /home/freundt/devel/datetools/info/datetools.texi freundt@plutos:~/devel_freundt/datetools/=build/info> ls datetools.info Makefile Cheers Sebastian From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 05:47:27 2011 Received: (at submit) by debbugs.gnu.org; 15 Sep 2011 09:47:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R48XX-0005BD-2u for submit@debbugs.gnu.org; Thu, 15 Sep 2011 05:47:27 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R48XV-0005B7-T4 for submit@debbugs.gnu.org; Thu, 15 Sep 2011 05:47:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R48T0-000177-T1 for submit@debbugs.gnu.org; Thu, 15 Sep 2011 05:42:48 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:60287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R48T0-000171-RN for submit@debbugs.gnu.org; Thu, 15 Sep 2011 05:42:46 -0400 Received: from eggs.gnu.org ([140.186.70.92]:48465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R48Sz-0002pS-7c for bug-automake@gnu.org; Thu, 15 Sep 2011 05:42:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R48Sw-00015E-76 for bug-automake@gnu.org; Thu, 15 Sep 2011 05:42:45 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:53920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R48Sv-00014F-Sv for bug-automake@gnu.org; Thu, 15 Sep 2011 05:42:42 -0400 Received: by wwp14 with SMTP id 14so2758996wwp.30 for ; Thu, 15 Sep 2011 02:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :x-kmail-markup:mime-version:message-id:content-type :content-transfer-encoding; bh=Qe5YQtsu9hjvYkvxE+nvoqUsfhSXDYk5Kl3pu5SQBAE=; b=heMWOmJukqYuERzOoUeUoI8s4bdj8gwAM6Mp0e1abp5s3BAycaa1Jw0d5d3nLargyE OBsI8SO8yZnKX4HcCRXHeWOe+JciytTJkY/WoYIWQIAEstZlH5ISDNn9WN2KFomuvB8b fJZDdmY8NOP4nh6I7il0ycBq7u3cu16L14/eE= Received: by 10.227.30.154 with SMTP id u26mr891301wbc.73.1316079760278; Thu, 15 Sep 2011 02:42:40 -0700 (PDT) Received: from bigio.localnet (host231-95-dynamic.244-95-r.retail.telecomitalia.it. [95.244.95.231]) by mx.google.com with ESMTPS id gd6sm7484543wbb.1.2011.09.15.02.42.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 02:42:37 -0700 (PDT) From: Stefano Lattarini To: bug-automake@gnu.org Subject: Re: bug#9506: makeinfo in VPATH builds fails Date: Thu, 15 Sep 2011 11:42:26 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; ) References: <81d3f35fxn.fsf@berlin.ga-group.nl> In-Reply-To: <81d3f35fxn.fsf@berlin.ga-group.nl> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109151142.27493.stefano.lattarini@gmail.com> Content-Type: multipart/alternative; boundary="Boundary-01=_DiccOdj+Wx1OjJ4" Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: 9506@debbugs.gnu.org, Sebastian Freundt X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.0 (-----) --Boundary-01=_DiccOdj+Wx1OjJ4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit tags 9506 wontfix close 9506 thanks Hi Sebastian, thanks for the bug report. On Wednesday 14 September 2011, Sebastian Freundt wrote: > Package: automake > Version: 1.11a > > VPATH build of a project using makeinfo fails if $(srcdir) isn't writable. > Yes, this is a consequence of the fact that `.info' files are "preferably" generated in the srcdir; the comments in automake explain in great detail why and how this is done: # Until Automake 1.6.3, .info files were built in the source tree. # This was an obstacle to the support of non-distributed `.info' # files, and non-distributed `.texi' files # # [SNIP] # # Back to the point, it should be clear that in order to support # non-distributed .info files, we need to build them in the build # tree, not in the source tree. In Automake 1.7 .info build rules # have been largely cleaned up so that .info files get always build # in the build tree, even when distributed. The idea was that # (1) if during a VPATH build the .info file was found to be # absent or out-of-date (in the source tree or in the # build tree), Make would rebuild it in the build tree. # If an up-to-date source-tree of the .info file existed, # make would not rebuild it in the build tree. # (2) having two copies of .info files, one in the source tree # and one (newer) in the build tree is not a problem because # `make dist' always pick files in the build tree first. # # However it turned out the be a bad idea for several reasons: # * Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave # like GNU Make on point (1) above. These implementations # of Make would always rebuild .info files in the build # tree, even if such files were up to date in the source # tree. Consequently, it was impossible to perform a VPATH # build of a package containing Texinfo files using these # Make implementations. # (Refer to the Autoconf Manual, section "Limitation of # Make", paragraph "VPATH", item "target lookup", for an # account of the differences between these implementations.) # * The GNU Coding Standards require these files to be built # in the source-tree (when they are distributed, that is). # * Keeping a fresher copy of distributed files in the # build tree can be annoying during development because # - if the files is kept under CVS, you really want it to be # updated in the source tree # - it is confusing that `make distclean' does not erase all # files in the build tree. # # Consequently, starting with Automake 1.8, .info files are # built in the source tree again. Because we still plan to # support non-distributed .info files at some point, we # have a single variable ($INSRC) that controls whether # the current .info file must be built in the source tree # or in the build tree. Actually this variable is switched # off for .info files that appear to be cleaned; this is # for backward compatibility with package such as Texinfo ... # # [SNIP] The main point is that if you're distributing you `.info' files, you should ensure that they are *not* rebuilt when building from a distribution tarball (as that would wreak havoce with at least FreeBSD make). OTOH, if you *want* them to be rebuilt, you should *not* distribute them, and *also* add them to CLEANFILES; in this case automake will build them in the buiilddir (if it doesn't, than that's a bug we should fix ASAP). I've marked this bug closed as "wontfix", but feel free to continue the discussion here if you have further doubts to clarify or ideas to contribute. Regards, Stefano --Boundary-01=_DiccOdj+Wx1OjJ4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

tags 9506 wontfix

close 9506

thanks


Hi Sebastian, thanks for the bug report.


On Wednesday 14 September 2011, Sebastian Freundt wrote:

> Package: automake

> Version: 1.11a

>

> VPATH build of a project using makeinfo fails if $(srcdir) isn't writable.

>

Yes, this is a consequence of the fact that `.info' files are "preferably"

generated in the srcdir; the comments in automake explain in great detail

why and how this is done:

# Until Automake 1.6.3, .info files were built in the source tree.

# This was an obstacle to the support of non-distributed `.info'

# files, and non-distributed `.texi' files

#

# [SNIP]

#

# Back to the point, it should be clear that in order to support

# non-distributed .info files, we need to build them in the build

# tree, not in the source tree. In Automake 1.7 .info build rules

# have been largely cleaned up so that .info files get always build

# in the build tree, even when distributed. The idea was that

# (1) if during a VPATH build the .info file was found to be

# absent or out-of-date (in the source tree or in the

# build tree), Make would rebuild it in the build tree.

# If an up-to-date source-tree of the .info file existed,

# make would not rebuild it in the build tree.

# (2) having two copies of .info files, one in the source tree

# and one (newer) in the build tree is not a problem because

# `make dist' always pick files in the build tree first.

#

# However it turned out the be a bad idea for several reasons:

# * Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave

# like GNU Make on point (1) above. These implementations

# of Make would always rebuild .info files in the build

# tree, even if such files were up to date in the source

# tree. Consequently, it was impossible to perform a VPATH

# build of a package containing Texinfo files using these

# Make implementations.

# (Refer to the Autoconf Manual, section "Limitation of

# Make", paragraph "VPATH", item "target lookup", for an

# account of the differences between these implementations.)

# * The GNU Coding Standards require these files to be built

# in the source-tree (when they are distributed, that is).

# * Keeping a fresher copy of distributed files in the

# build tree can be annoying during development because

# - if the files is kept under CVS, you really want it to be

# updated in the source tree

# - it is confusing that `make distclean' does not erase all

# files in the build tree.

#

# Consequently, starting with Automake 1.8, .info files are

# built in the source tree again. Because we still plan to

# support non-distributed .info files at some point, we

# have a single variable ($INSRC) that controls whether

# the current .info file must be built in the source tree

# or in the build tree. Actually this variable is switched

# off for .info files that appear to be cleaned; this is

# for backward compatibility with package such as Texinfo ...

#

# [SNIP]

The main point is that if you're distributing you `.info' files, you should

ensure that they are *not* rebuilt when building from a distribution tarball

(as that would wreak havoce with at least FreeBSD make). OTOH, if you *want*

them to be rebuilt, you should *not* distribute them, and *also* add them to

CLEANFILES; in this case automake will build them in the buiilddir (if it

doesn't, than that's a bug we should fix ASAP).

I've marked this bug closed as "wontfix", but feel free to continue the

discussion here if you have further doubts to clarify or ideas to contribute.


Regards,

Stefano

--Boundary-01=_DiccOdj+Wx1OjJ4-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 07:14:33 2011 Received: (at submit) by debbugs.gnu.org; 15 Sep 2011 11:14:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R49tn-0002fe-QA for submit@debbugs.gnu.org; Thu, 15 Sep 2011 07:14:33 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R49tl-0002fX-9D for submit@debbugs.gnu.org; Thu, 15 Sep 2011 07:14:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R49pG-0005Ey-1J for submit@debbugs.gnu.org; Thu, 15 Sep 2011 07:09:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:34683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49pF-0005Eu-W3 for submit@debbugs.gnu.org; Thu, 15 Sep 2011 07:09:50 -0400 Received: from eggs.gnu.org ([140.186.70.92]:39566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49pE-0004Q2-IG for bug-automake@gnu.org; Thu, 15 Sep 2011 07:09:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R49pD-0005C1-6L for bug-automake@gnu.org; Thu, 15 Sep 2011 07:09:48 -0400 Received: from mr011.hansenet.de ([85.183.254.144]:33749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49pC-00056e-Me for bug-automake@gnu.org; Thu, 15 Sep 2011 07:09:47 -0400 Received: from segen.fresse.org (85.183.32.27) by mr011.hansenet.de (8.5.134) id 4D25AFBC00C0FD7E for bug-automake@gnu.org; Thu, 15 Sep 2011 13:09:41 +0200 Received: by segen.fresse.org (Postfix, from userid 112) id D770A206FB; Thu, 15 Sep 2011 11:09:40 +0000 (UTC) Received: from segen.fresse.org (segen.fresse.org [IPv6:2a01:198:5b7::7e]) by segen.fresse.org (Postfix) with ESMTP id 6D504206F6; Thu, 15 Sep 2011 11:09:37 +0000 (UTC) From: Sebastian Freundt To: Stefano Lattarini Subject: Re: bug#9506: makeinfo in VPATH builds fails In-Reply-To: <201109151142.27493.stefano.lattarini@gmail.com> (Stefano Lattarini's message of "Thu, 15 Sep 2011 11:42:26 +0200") References: <81d3f35fxn.fsf@berlin.ga-group.nl> <201109151142.27493.stefano.lattarini@gmail.com> User-Agent: Gnus/5.110014 (No Gnus v0.14) SXEmacs/22.1.12 (linux) X-URL: http://www.math.tu-berlin.de/~freundt/ X-Gpg-Key-Id: 0x82C9390E X-Fingerprint: 6CB0 D61E 23A4 275C C2CF A161 94C9 A1AC 82C9 390E X-Face: #HUK$+njZzfa\Y7-C?%}`0I+_5(GhEOmLsy4}, ^7)im*%||Zh=:FnuCpe1gt+p:Omkx{a}BSf}DSn4], m9[bw5*gsG$Xx<-V"(L0?M8*&H\hh^^cd7F~B=/KkLl\mNdk\_}HrPG}=cnAwt=\tWF6J X-Discordian-Date: Pungenday, 39th of Bureaucracy, yold 3177. Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWLYy//y8qfMzN/UVL/ l5eamX/LmWbRZmLMmZjg3qv+zZf7/vr727f6AAACVklEQVR42o3UMWvbQBQA4CPG8dDJNBRXXUwy ZHURoS1d2iJkVVNIcNI0i8GXp6unEMMpY0uU68WdAmmRm8lwpOJtpgSi5s/1To6lS2mhN+rTu/f0 7p3I7T8W+T84n/wFrm9Od3rbvS9/Qr47IoSsdmp7l/dhs8GXNKy2yf49eNjmlMbAedRe27dgtrWc hOh5gD6QlxbcLEGi0CzlR3ULfq7LBOfLg5EFW8vBGLHpmBAY7Jcw67AgRJwaQD96WsEykxqcu72e V1vFwEJcJBlvlHC9U4Hy/O0nZUQEML7LoWFQbdUHoDhtFmUFooJ0wIFJXW9z2kQlBuVWX3e5Th/x 4dTECPMhBcw+fjvmMnxsKhAxj2olqFqDy8kpMMziBnCygAv1pjFiB+8EhD4A9OsLWMFXPn0rpRDD 6FPv2WEZ0Qp+cJqhSnzaTc86hCzKXQmvYmo6BbQLIiJl8gtsFaAE9UEAWVtEnGvQHcGpHypG4ai+ gNzJ4uKc4LVDBYselC1xfA1OUwXDbOgFUdX22SOe6N4qCtFQBaPqaPPWcVJ0HCFUAangVpjeGvCp 8l1rSiRLx8X5ZYkSNQvSD5kBDzMp+xsWtBimeBXHMUgxsEd0j71PEaNuvD4U/RcW/BLj1CTvxuPT gT3tjpCmrGBFfofOfShmQemvgG374pxJJuf1ik3XjriW0ow7KhSHdStCP5fziKA/v1AWCJMdZd+1 LmcuWRKm8gwnKF0Lct1DT7+sV/rZdasfwGUOBhSmIjpyXesHkAt2dznEQc/ds5LrHk4LODmY9OY5 fgNaH4km3mN9MwAAAABJRU5ErkJggg== Date: Thu, 15 Sep 2011 11:09:37 +0000 Message-ID: <87pqj2vz7y.fsf@segen.fresse.org> MIME-Version: 1.0 Content-Type: text/plain X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.1 X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit Cc: bug-automake@gnu.org, 9506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.8 (----) Stefano Lattarini writes: > tags 9506 wontfix > close 9506 > thanks > > Hi Sebastian, thanks for the bug report. > > On Wednesday 14 September 2011, Sebastian Freundt wrote: >> Package: automake >> Version: 1.11a >> >> VPATH build of a project using makeinfo fails if $(srcdir) isn't writable. >> > Yes, this is a consequence of the fact that `.info' files are "preferably" > generated in the srcdir; the comments in automake explain in great detail > why and how this is done: > > # Until Automake 1.6.3, .info files were built in the source tree. > # This was an obstacle to the support of non-distributed `.info' > # files, and non-distributed `.texi' files > # > # [SNIP] > # > # Back to the point, it should be clear that in order to support > # non-distributed .info files, we need to build them in the build > # tree, not in the source tree. In Automake 1.7 .info build rules > # have been largely cleaned up so that .info files get always build > # in the build tree, even when distributed. The idea was that > # (1) if during a VPATH build the .info file was found to be > # absent or out-of-date (in the source tree or in the > # build tree), Make would rebuild it in the build tree. > # If an up-to-date source-tree of the .info file existed, > # make would not rebuild it in the build tree. > # (2) having two copies of .info files, one in the source tree > # and one (newer) in the build tree is not a problem because > # `make dist' always pick files in the build tree first. > # > # However it turned out the be a bad idea for several reasons: > # * Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave > # like GNU Make on point (1) above. These implementations > # of Make would always rebuild .info files in the build > # tree, even if such files were up to date in the source > # tree. Consequently, it was impossible to perform a VPATH > # build of a package containing Texinfo files using these > # Make implementations. > # (Refer to the Autoconf Manual, section "Limitation of > # Make", paragraph "VPATH", item "target lookup", for an > # account of the differences between these implementations.) > # * The GNU Coding Standards require these files to be built > # in the source-tree (when they are distributed, that is). > # * Keeping a fresher copy of distributed files in the > # build tree can be annoying during development because > # - if the files is kept under CVS, you really want it to be > # updated in the source tree > # - it is confusing that `make distclean' does not erase all > # files in the build tree. > # > # Consequently, starting with Automake 1.8, .info files are > # built in the source tree again. Because we still plan to > # support non-distributed .info files at some point, we > # have a single variable ($INSRC) that controls whether > # the current .info file must be built in the source tree > # or in the build tree. Actually this variable is switched > # off for .info files that appear to be cleaned; this is > # for backward compatibility with package such as Texinfo ... > # > # [SNIP] > > The main point is that if you're distributing you `.info' files, you should > ensure that they are *not* rebuilt when building from a distribution tarball > (as that would wreak havoce with at least FreeBSD make). OTOH, if you *want* > them to be rebuilt, you should *not* distribute them, and *also* add them to > CLEANFILES; in this case automake will build them in the buiilddir (if it > doesn't, than that's a bug we should fix ASAP). > > I've marked this bug closed as "wontfix", but feel free to continue the > discussion here if you have further doubts to clarify or ideas to contribute. Hi Stefano, I've followed your suggestions, and prefixed the TEXINFOS with `nodist_' and added them to CLEANFILES, however the .info file is now neither built nor installed (even upon make install-info). In my case the .info files should be rebuilt and not distributed as they contain partially auto-generated content. Another bug report? Cheers Sebastian From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 07:39:29 2011 Received: (at 9506) by debbugs.gnu.org; 15 Sep 2011 11:39:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R4AHw-0004nx-0R for submit@debbugs.gnu.org; Thu, 15 Sep 2011 07:39:28 -0400 Received: from mail-wy0-f172.google.com ([74.125.82.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R4AHs-0004nk-7y; Thu, 15 Sep 2011 07:39:26 -0400 Received: by wyg24 with SMTP id 24so2305389wyg.3 for ; Thu, 15 Sep 2011 04:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :x-kmail-markup:mime-version:content-type:content-transfer-encoding :message-id; bh=7PmllUBXhpPdoF/UZDhTQHy20Gh3zJOBejvUC+b6odQ=; b=tPEpdBLf//vE3WwoBcKLQzETTGsY81jgSmrgg7p3P7GvhhAXTW+qxWzWBUSJfMnB0G DY+VKJ77MlcrGzBQk/5YVOpdfm4YDkGl4c+/yWBOwi4AgCfZ/ekfDSh7LbLM9iOZXdfW l2EZHmFZhk5MGsc1nx7P4MzgXx3Xd2b49CNgE= Received: by 10.216.199.205 with SMTP id x55mr961509wen.42.1316086483778; Thu, 15 Sep 2011 04:34:43 -0700 (PDT) Received: from bigio.localnet (host231-95-dynamic.244-95-r.retail.telecomitalia.it. [95.244.95.231]) by mx.google.com with ESMTPS id er8sm7494315wbb.0.2011.09.15.04.34.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 04:34:42 -0700 (PDT) From: Stefano Lattarini To: Sebastian Freundt , 9506@debbugs.gnu.org Subject: TEXINFOS primary and nodist_ (was: Re: makeinfo in VPATH builds fails) Date: Thu, 15 Sep 2011 13:34:23 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; ) References: <81d3f35fxn.fsf@berlin.ga-group.nl> <201109151142.27493.stefano.lattarini@gmail.com> <87pqj2vz7y.fsf@segen.fresse.org> In-Reply-To: <87pqj2vz7y.fsf@segen.fresse.org> X-KMail-Markup: true MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-01=_ALecOb0JrRy2I/Z" Content-Transfer-Encoding: 7bit Message-Id: <201109151334.24315.stefano.lattarini@gmail.com> X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: 9506 Cc: bug-automake@gnu.org, 7657@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) --Boundary-01=_ALecOb0JrRy2I/Z Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Submitter: Sebastian Freundt thanks Reference: On Thursday 15 September 2011, Sebastian Freundt wrote: > Stefano Lattarini writes: > > > The main point is that if you're distributing you `.info' files, you should > > ensure that they are *not* rebuilt when building from a distribution tarball > > (as that would wreak havoce with at least FreeBSD make). OTOH, if you *want* > > them to be rebuilt, you should *not* distribute them, and *also* add them to > > CLEANFILES; in this case automake will build them in the buiilddir (if it > > doesn't, than that's a bug we should fix ASAP). > > > > I've marked this bug closed as "wontfix", but feel free to continue the > > discussion here if you have further doubts to clarify or ideas to contribute. > > > Hi Stefano, > > I've followed your suggestions, and prefixed the TEXINFOS with `nodist_' > and added them to CLEANFILES, however the .info file is now neither built > nor installed (even upon make install-info). > Hmpf, yes, this is another limitation/incompatibility of the TEXINFOS primary; the only ways TEXINFOS can by used are: # Will cause generation of foo.info, foo.pdf, etc. info_TEXINFOS = foo.texi # Will declare that these files ae required when building `foo.texi' foo_TEXINFOS = bar.texi baz.texi So, when automake sees nodist_TEXINFOS, it thinks that it just lists extra `.texi' files required by `nodist.texi' ... And it doesn't even warn that `nodist.texi' is not really used anywhere! There is already a bug report about this situation: but I had forgotten about it. Thanks for reminding me! > > In my case the .info files should be rebuilt and not distributed as they > contain partially auto-generated content. > OK. Maybe you might use a dist-hook to remove the `.info' files not intended for distribution from the distdir, just before the distribution tarball is created. See: > Another bug report? > Good idea. I've already opened it (hopefully in your name, otherwise I'll fix that later). > Cheers > Sebastian > Thanks, Stefano --Boundary-01=_ALecOb0JrRy2I/Z Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

Submitter: Sebastian Freundt <devel@fresse.org>

thanks


Reference:

<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9506>


On Thursday 15 September 2011, Sebastian Freundt wrote:

> Stefano Lattarini <stefano.lattarini@gmail.com> writes:

>

> > The main point is that if you're distributing you `.info' files, you should

> > ensure that they are *not* rebuilt when building from a distribution tarball

> > (as that would wreak havoce with at least FreeBSD make). OTOH, if you *want*

> > them to be rebuilt, you should *not* distribute them, and *also* add them to

> > CLEANFILES; in this case automake will build them in the buiilddir (if it

> > doesn't, than that's a bug we should fix ASAP).

> >

> > I've marked this bug closed as "wontfix", but feel free to continue the

> > discussion here if you have further doubts to clarify or ideas to contribute.

>

>

> Hi Stefano,

>

> I've followed your suggestions, and prefixed the TEXINFOS with `nodist_'

> and added them to CLEANFILES, however the .info file is now neither built

> nor installed (even upon make install-info).

>

Hmpf, yes, this is another limitation/incompatibility of the TEXINFOS

primary; the only ways TEXINFOS can by used are:


# Will cause generation of foo.info, foo.pdf, etc.

info_TEXINFOS = foo.texi

# Will declare that these files ae required when building `foo.texi'

foo_TEXINFOS = bar.texi baz.texi


So, when automake sees nodist_TEXINFOS, it thinks that it just lists extra

`.texi' files required by `nodist.texi' ... And it doesn't even warn that

`nodist.texi' is not really used anywhere!


There is already a bug report about this situation:

<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7657>

but I had forgotten about it. Thanks for reminding me!


>

> In my case the .info files should be rebuilt and not distributed as they

> contain partially auto-generated content.

>

OK. Maybe you might use a dist-hook to remove the `.info' files not

intended for distribution from the distdir, just before the distribution

tarball is created. See:

<http://www.gnu.org/software/automake/manual/html_node/The-dist-Hook.html>


> Another bug report?

>

Good idea. I've already opened it (hopefully in your name, otherwise I'll

fix that later).

> Cheers

> Sebastian

>


Thanks,

Stefano

--Boundary-01=_ALecOb0JrRy2I/Z-- From unknown Fri Aug 15 02:02:21 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 14 Oct 2011 11:24:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator