Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches

[Stefano Lattarini]

On Friday 11 February 2011, Ralf Wildenhues wrote:
 Hi Stefano,
 
 * Stefano Lattarini wrote on Wed, Feb 02, 2011 at 12:10:15AM CET:
  Subject: [PATCH] python: extend and improve tests, fix minor glitches
  
 [...]
  * tests/python-vars.test: New test, checking that AM_PATH_PYTHON
  correctly set all the output variables advertised in the manual.
 
 This test fails for me, see below.

Yes, I can reproduce this with my system-level installation of python3
on Debian (I had previously checked the test only with custom python
installations -- both 2.x and 3.x -- which all worked as expected).

The attached patch should fix this.

 As a minor nit, the test trace contains hyped output again, I think
   echo $var=$val
 and
   echo $var=@$var@
 
 would have resulted in both smaller trace output and also more
 informative diff.

Agreed.  The attached patch addresses this too.

OK to apply?  I will push in 72 hours if there are no further
objections.

Thanks,
   Stefano

 Cheers,
 Ralf
 
 FAIL: python-vars.test (exit: 2)
 
 
 /tmp/automake/build/tests:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 python-vars: running python -V
 Python 2.6.5
 + set -e
 + pwd
 /tmp/automake/build/tests/python-vars.dir
 + set -e
 + PYTHON=python
 + python -c import sys; print(sys.version[:3])
 + PYTHON_VERSION=2.6
 + python -c import sys; print(sys.platform)
 + PYTHON_PLATFORM=linux2
 + PYTHON_EXEC_PREFIX=${exec_prefix}
 + PYTHON_PREFIX=${prefix}
 + pythondir=${prefix}/lib/python2.6/site-packages
 + pyexecdir=${exec_prefix}/lib/python2.6/site-packages
 + pkgpythondir=${pythondir}/python-vars
 + pkgpyexecdir=${pyexecdir}/python-vars
 + pyvars=PYTHON_VERSION PYTHON_PLATFORM PYTHON_PREFIX PYTHON_EXEC_PREFIX
 pythondir pyexecdir pkgpythondir pkgpyexecdir
 + cat
 + cat
 + cat
 + echo
 + echo
 + echo test-am:
 + eval val=$PYTHON_VERSION
 + val=2.6
 + echo ### PYTHON_VERSION ###
 + echo 2.6
 + echo
 + echo ### PYTHON_VERSION ###
 + echo @PYTHON_VERSION@
 + echo
 + echotest x'$(PYTHON_VERSION)' = x'2.6'
 + eval val=$PYTHON_PLATFORM
 + val=linux2
 + echo ### PYTHON_PLATFORM ###
 + echo linux2
 + echo
 + echo ### PYTHON_PLATFORM ###
 + echo @PYTHON_PLATFORM@
 + echo
 + echotest x'$(PYTHON_PLATFORM)' = x'linux2'
 + eval val=$PYTHON_PREFIX
 + val=${prefix}
 + echo ### PYTHON_PREFIX ###
 + echo ${prefix}
 + echo
 + echo ### PYTHON_PREFIX ###
 + echo @PYTHON_PREFIX@
 + echo
 + echotest x'$(PYTHON_PREFIX)' = x'${prefix}'
 + eval val=$PYTHON_EXEC_PREFIX
 + val=${exec_prefix}
 + echo ### PYTHON_EXEC_PREFIX ###
 + echo ${exec_prefix}
 + echo
 + echo ### PYTHON_EXEC_PREFIX ###
 + echo @PYTHON_EXEC_PREFIX@
 + echo
 + echotest x'$(PYTHON_EXEC_PREFIX)' = x'${exec_prefix}'
 + eval val=$pythondir
 + val=${prefix}/lib/python2.6/site-packages
 + echo ### pythondir ###
 + echo ${prefix}/lib/python2.6/site-packages
 + echo
 + echo ### pythondir ###
 + echo @pythondir@
 + echo
 + echotest x'$(pythondir)' = x'${prefix}/lib/python2.6/site-packages'
 + eval val=$pyexecdir
 + val=${exec_prefix}/lib/python2.6/site-packages
 + echo ### pyexecdir ###
 + echo ${exec_prefix}/lib/python2.6/site-packages
 + echo
 + echo ### pyexecdir ###
 + echo @pyexecdir@
 + echo
 + echotest x'$(pyexecdir)' = 
 x'${exec_prefix}/lib/python2.6/site-packages'
 + eval val=$pkgpythondir
 + val=${pythondir}/python-vars
 + echo ### pkgpythondir ###
 + echo ${pythondir}/python-vars
 + echo
 + echo ### pkgpythondir ###
 + echo @pkgpythondir@
 + echo
 + echotest x'$(pkgpythondir)' = x'${pythondir}/python-vars'
 + eval val=$pkgpyexecdir
 + val=${pyexecdir}/python-vars
 + echo ### pkgpyexecdir ###
 + echo ${pyexecdir}/python-vars
 + echo
 + echo ### pkgpyexecdir ###
 + echo @pkgpyexecdir@
 + echo
 + echotest x'$(pkgpyexecdir)' = x'${pyexecdir}/python-vars'
 + cat Makefile.am
 
 python_PYTHON = my.py
 
 EXTRA_DIST = vars-exp
 
 check-local: test-in test-am
 .PHONY: test-in test-am
 
 test-in:
   cat $(srcdir)/vars-exp
   cat $(builddir)/vars-got
   diff $(srcdir)/vars-exp $(builddir)/vars-got
 test-am:
   test x'$(PYTHON_VERSION)' = x'2.6'
   test x'$(PYTHON_PLATFORM)' = x'linux2'
   test x'$(PYTHON_PREFIX)' = x'${prefix}'
   test x'$(PYTHON_EXEC_PREFIX)' = x'${exec_prefix}'
   test x'$(pythondir)' = x'${prefix}/lib/python2.6/site-packages'
   test x'$(pyexecdir)' = x'${exec_prefix}/lib/python2.6/site-packages'
   test x'$(pkgpythondir)' = x'${pythondir}/python-vars'
   test x'$(pkgpyexecdir)' = x'${pyexecdir}/python-vars'
 + cat vars-got.in
 
 ### PYTHON_VERSION ###
 @PYTHON_VERSION@
 
 ### PYTHON_PLATFORM ###
 @PYTHON_PLATFORM@
 
 ### PYTHON_PREFIX ###
 @PYTHON_PREFIX@
 
 ### PYTHON_EXEC_PREFIX ###
 @PYTHON_EXEC_PREFIX@
 
 ### pythondir ###
 @pythondir@
 
 ### pyexecdir ###
 @pyexecdir@
 
 ### pkgpythondir ###
 @pkgpythondir@
 
 ### pkgpyexecdir ###
 @pkgpyexecdir@
 
 + aclocal-1.11a -Werror
 + automake-1.11a --foreign -Werror 

Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches

[Ralf Wildenhues]

* Stefano Lattarini wrote on Sun, Feb 13, 2011 at 11:49:28AM CET:
 OK to apply?  I will push in 72 hours if there are no further
 objections.

The patch is OK as it is a strict improvement IIUC, but I still have a
question below.

Thanks,
Ralf

 Subject: [PATCH] python: fix spurious failure in tests
 
 * tests/python-vars.test: Be laxer in matching the expected values
 of output variables `pythondir' and `pyexecdir', since they can
 change quite unpredictably among different python installations.
 Also, avoid hyping debugging output, thus offering smaller trace
 output and more informative diff.

 --- a/tests/python-vars.test
 +++ b/tests/python-vars.test
 @@ -24,21 +24,23 @@ set -e
  
  PYTHON=python
  
 -# Update these if the documentation changes.
 +# Update the definition below if the documentation changes.
 +# Note that the value of the `pythondir' and `pyexecdir' variables can
 +# vary among different python installations, so we need more relaxed
 +# and ad-hoc checks for them.  Also, more proper functional checks
 +# on them should be done in the `python-virtualenv.test' test.
  PYTHON_VERSION=`$PYTHON -c 'import sys; print(sys.version[:3])'` || Exit 1
  PYTHON_PLATFORM=`$PYTHON -c 'import sys; print(sys.platform)'` || Exit 1
  PYTHON_EXEC_PREFIX='${exec_prefix}'
  PYTHON_PREFIX='${prefix}'
 -pythondir=\${prefix}/lib/python$PYTHON_VERSION/site-packages
 -pyexecdir=\${exec_prefix}/lib/python$PYTHON_VERSION/site-packages
  pkgpythondir=\${pythondir}/$me
  pkgpyexecdir=\${pyexecdir}/$me
  
  pyvars='PYTHON_VERSION PYTHON_PLATFORM PYTHON_PREFIX PYTHON_EXEC_PREFIX
 -pythondir pyexecdir pkgpythondir pkgpyexecdir'
 +pkgpythondir pkgpyexecdir'
  
  cat  configure.in  'END'
 -AC_CONFIG_FILES([vars-got])
 +AC_CONFIG_FILES([vars-got pythondir pyexecdir])
  AM_PATH_PYTHON
  AC_OUTPUT
  END
 @@ -58,19 +60,30 @@ check-local: test-in test-am
  .PHONY: test-in test-am
  
  test-in:
 + cat pythondir
 + case `cat pythondir` in '$${prefix}'/*);; *) exit 1;; esac
 + cat pyexecdir
 + case `cat pyexecdir` in '$${exec_prefix}'/*);; *) exit 1;; esac

This is probably pragmatically correct most anywhere, but I don't think
we require pyexecdir to start with ${exec_prefix}.  The user can
override it, for example by a cache variable entry in config.site, no?

Tests should generally be lax wrt. sane config.site entries.  When we
meet insane ones, we may want to decide to disable it for our testsuite,
but let's cross that bridge when we get to it.

   cat $(srcdir)/vars-exp
   cat $(builddir)/vars-got
   diff $(srcdir)/vars-exp $(builddir)/vars-got
 +
 +## Note: this target's rules will be extended in the for loop below.
 +test-am:
 + case '$(pythondir)' in '$(prefix)'/*);; *) exit 1;; esac
 + case '$(pyexecdir)' in '$(exec_prefix)'/*);; *) exit 1;; esac

Same here.

  END

Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches

[Stefano Lattarini]

On Sunday 13 February 2011, Ralf Wildenhues wrote:
 * Stefano Lattarini wrote on Sun, Feb 13, 2011 at 11:49:28AM CET:
  OK to apply?  I will push in 72 hours if there are no further
  objections.
 
 The patch is OK as it is a strict improvement IIUC, but I still have a
 question below.
 
 Thanks,
 Ralf
 
  Subject: [PATCH] python: fix spurious failure in tests
  
  * tests/python-vars.test: Be laxer in matching the expected values
  of output variables `pythondir' and `pyexecdir', since they can
  change quite unpredictably among different python installations.
  Also, avoid hyping debugging output, thus offering smaller trace
  output and more informative diff.
 
  --- a/tests/python-vars.test
  +++ b/tests/python-vars.test
  @@ -24,21 +24,23 @@ set -e
   
   PYTHON=python
   
  -# Update these if the documentation changes.
  +# Update the definition below if the documentation changes.
  +# Note that the value of the `pythondir' and `pyexecdir' variables can
  +# vary among different python installations, so we need more relaxed
  +# and ad-hoc checks for them.  Also, more proper functional checks
  +# on them should be done in the `python-virtualenv.test' test.
   PYTHON_VERSION=`$PYTHON -c 'import sys; print(sys.version[:3])'` || Exit 1
   PYTHON_PLATFORM=`$PYTHON -c 'import sys; print(sys.platform)'` || Exit 1
   PYTHON_EXEC_PREFIX='${exec_prefix}'
   PYTHON_PREFIX='${prefix}'
  -pythondir=\${prefix}/lib/python$PYTHON_VERSION/site-packages
  -pyexecdir=\${exec_prefix}/lib/python$PYTHON_VERSION/site-packages
   pkgpythondir=\${pythondir}/$me
   pkgpyexecdir=\${pyexecdir}/$me
   
   pyvars='PYTHON_VERSION PYTHON_PLATFORM PYTHON_PREFIX PYTHON_EXEC_PREFIX
  -pythondir pyexecdir pkgpythondir pkgpyexecdir'
  +pkgpythondir pkgpyexecdir'
   
   cat  configure.in  'END'
  -AC_CONFIG_FILES([vars-got])
  +AC_CONFIG_FILES([vars-got pythondir pyexecdir])
   AM_PATH_PYTHON
   AC_OUTPUT
   END
  @@ -58,19 +60,30 @@ check-local: test-in test-am
   .PHONY: test-in test-am
   
   test-in:
  +   cat pythondir
  +   case `cat pythondir` in '$${prefix}'/*);; *) exit 1;; esac
  +   cat pyexecdir
  +   case `cat pyexecdir` in '$${exec_prefix}'/*);; *) exit 1;; esac
 
 This is probably pragmatically correct most anywhere, but I don't think
 we require pyexecdir to start with ${exec_prefix}.  The user can
 override it, for example by a cache variable entry in config.site, no?

Yes, but than he could do so also for `pythondir' -- which would cause
failures in both `python-vars.test' and `python-virtualenv.test'.  Maybe
the best fix would be to `export CONFIG_SITE=/dev/null' in these tests?
Or should we start caring about those cache variables only once (and if)
they start creating real troubles?

 Tests should generally be lax wrt. sane config.site entries.  When we
 meet insane ones, we may want to decide to disable it for our testsuite,
 but let's cross that bridge when we get to it.
 
  cat $(srcdir)/vars-exp
  cat $(builddir)/vars-got
  diff $(srcdir)/vars-exp $(builddir)/vars-got
  +
  +## Note: this target's rules will be extended in the for loop below.
  +test-am:
  +   case '$(pythondir)' in '$(prefix)'/*);; *) exit 1;; esac
  +   case '$(pyexecdir)' in '$(exec_prefix)'/*);; *) exit 1;; esac
 
 Same here.
 
   END
 

Also, as an aside, now that $pyvars does not contain anymore `pythondir'
and `pyexecdir', I think we should also squash-in the following diff in
the test.  OK?

-*-*-

diff --git a/tests/python-vars.test b/tests/python-vars.test
index 2242691..ab2fe35 100755
--- a/tests/python-vars.test
+++ b/tests/python-vars.test
@@ -93,7 +93,7 @@ cat vars-got.in
 $ACLOCAL
 $AUTOMAKE --add-missing
 
-for var in $pyvars; do
+for var in pythondir pyexecdir $pyvars; do
   grep ^$var *= Makefile.in
 done

Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches

[Ralf Wildenhues]

* Stefano Lattarini wrote on Sun, Feb 13, 2011 at 02:09:03PM CET:
 On Sunday 13 February 2011, Ralf Wildenhues wrote:
  * Stefano Lattarini wrote on Sun, Feb 13, 2011 at 11:49:28AM CET:
   + cat pythondir
   + case `cat pythondir` in '$${prefix}'/*);; *) exit 1;; esac
   + cat pyexecdir
   + case `cat pyexecdir` in '$${exec_prefix}'/*);; *) exit 1;; esac
  
  This is probably pragmatically correct most anywhere, but I don't think
  we require pyexecdir to start with ${exec_prefix}.  The user can
  override it, for example by a cache variable entry in config.site, no?
 
 Yes, but than he could do so also for `pythondir' -- which would cause
 failures in both `python-vars.test' and `python-virtualenv.test'.  Maybe
 the best fix would be to `export CONFIG_SITE=/dev/null' in these tests?

OK.  That is, 'CONFIG_SITE=/dev/null; export CONFIG_SITE' of course.

 Or should we start caring about those cache variables only once (and if)
 they start creating real troubles?

However you like.  Since we've determined this test to be potentially
problematic already, we can address it now and stop worrying.

  Tests should generally be lax wrt. sane config.site entries.  When we
  meet insane ones, we may want to decide to disable it for our testsuite,
  but let's cross that bridge when we get to it.

 Also, as an aside, now that $pyvars does not contain anymore `pythondir'
 and `pyexecdir', I think we should also squash-in the following diff in
 the test.  OK?

Sure, why not.

Thanks,
Ralf

 --- a/tests/python-vars.test
 +++ b/tests/python-vars.test
 @@ -93,7 +93,7 @@ cat vars-got.in
  $ACLOCAL
  $AUTOMAKE --add-missing
  
 -for var in $pyvars; do
 +for var in pythondir pyexecdir $pyvars; do
grep ^$var *= Makefile.in
  done

Re: turning off dependency tracking when building fat binaries on Mac OSX

[Ralf Wildenhues]

Hello Peter,

* Peter Johansson wrote on Sat, Jan 22, 2011 at 05:18:10PM CET:
 The `INSTALL' file provided by autotools has the following blurp
 
On MacOS X 10.5 and later systems, you can create libraries and
 executables that work on multiple system types--known as fat or
 universal binaries--by specifying multiple `-arch' options to the
 compiler but only a single `-arch' option to the preprocessor.  Like
 this:
 
  ./configure CC=gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64 \
  CXX=g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64 \
  CPP=gcc -E CXXCPP=g++ -E
 
 I noticed that when configuring like that automake automagically
 turns off dependency-tracking, for good reasons.
 
 However, it is not uncommon that people instead issue
 
 ./configure CFLAGS=-arch i386 -arch x86_64 -arch ppc -arch ppc64 \
 CXXFLAGS=-arch i386 -arch x86_64 -arch ppc -arch ppc64 \
 LDFLAGS=-arch i386 -arch x86_64 -arch ppc -arch ppc64
 
 which will not works. See for example
 
 http://www.mail-archive.com/help-gsl@gnu.org/msg03121.html

Yep.  I think that was one reason we explicitly documented the thing in
INSTALL.  With this configuration, your preprocessor will be wrong
(because CFLAGS are not passed to it) which means macro values may be
computed wrongly.

That doesn't mean we should break automake dependency tracking in this
configuration, but it does mean you shouldn't do it when it hurts.  ;-)

 You need to explicitly turn off dependency tracking. My question is
 simply is there a good reason why automake does not turn off the
 dependency tracking automagically in this case, or should I consider
 it a missing feature.

I suppose I'll accept a patch that enhances automake/m4/depend.m4 to
address this.  Are you motivated?

Cheers, and thanks for the report,
Ralf

Re: slow make clean

[Ralf Hemmecke]

You mean, as a workaround until Automake is improved?  You could
overwrite the rule in your Makefile.am:

mostlyclean-compile:
-find . -name \*.lo -o -name \*.$(OBJEXT) -print | xargs rm -f

But note that automake may generate other files that would need to be
mostlyclean'ed too, so the above could be insufficient for your project.


Thanks, that seems to work as a workaround. But, of course, it would be 
good, if I knew what will be generated, so that I can clean everything 
even when Makefile.am changes slightly. Is there a variable that already 
contains every name of MAKE-generated files?



Thanks for the report,


No problem. But I was a bit surprised that I haven't found any proper 
bugtracker. Now, I have to subscribe to automake-patches and try to 
figure out when automake will have improvements that fix the slow make 
clean problem instead of just subscribing to the specific bug report.


Ralf

Re: slow make clean

[Ralf Wildenhues]

* Ralf Hemmecke wrote on Sun, Feb 13, 2011 at 03:10:39PM CET:
 You mean, as a workaround until Automake is improved?  You could
 overwrite the rule in your Makefile.am:
 
 mostlyclean-compile:
  -find . -name \*.lo -o -name \*.$(OBJEXT) -print | xargs rm -f
 
 But note that automake may generate other files that would need to be
 mostlyclean'ed too, so the above could be insufficient for your project.
 
 Thanks, that seems to work as a workaround.

(BTW, just in case anyone is wondering now: the above rule is not
suitable for use in Automake because it can be severely suboptimal
if, say, only a couple of objects are built in the current directory
but there is a huge build directory tree which find would traverse.)

 But, of course, it would be
 good, if I knew what will be generated, so that I can clean everything even
 when Makefile.am changes slightly. Is there a variable that already contains
 every name of MAKE-generated files?

Nope, sorry.

 Thanks for the report,
 
 No problem. But I was a bit surprised that I haven't found any proper
 bugtracker. Now, I have to subscribe to automake-patches and try to figure
 out when automake will have improvements that fix the slow make clean
 problem instead of just subscribing to the specific bug report.

We have a bug tracker.  Just write to the bug-automake list.
This is documented at
http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html
which is linked from the Automake home page
http://www.gnu.org/software/automake/

Cheers,
Ralf

Re: slow make clean

[Ralf Hemmecke]

We have a bug tracker.  Just write to the bug-automake list.
This is documented at
http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html


Oh yes, but it's not completely clear to me whether I get only an email 
for a bug that I submitted or whether I can explicitly can subscribed to 
some specific bug-thread.


...similar to what for example the roundup-tracker can do. The python 
people use it. The Nosy list is what I am referring to.


http://bugs.python.org/issue1294032

I think I would get too many (to me irrelevant) mails if I subscribe to 
the bug-automake mailing list.


Ralf

debbugs and (was: slow make clean)

[Ralf Wildenhues]

* Ralf Hemmecke wrote on Sun, Feb 13, 2011 at 06:46:12PM CET:
 We have a bug tracker.  Just write to the bug-automake list.
 This is documented at
 http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html
 
 Oh yes, but it's not completely clear to me whether I get only an
 email for a bug that I submitted or whether I can explicitly can
 subscribed to some specific bug-thread.

First off, you do not need to be subscribed to bug-automake in order to
post there.  We have a habit of Cc:ing the author (and rest of people
already in Cc:) when replying, so non-subscribers can follow the
discussion.  We don't always get this completely right, and people
replying via web interfaces a la gmane can't easily follow this, but
usually it works OK.

I glanced over the debbugs documentation at debbugs.gnu.org now, but
couldn't find a place that said something about subscribing to
individual bugs.  Glen, do you happen to know more about this?

 ...similar to what for example the roundup-tracker can do. The
 python people use it. The Nosy list is what I am referring to.
 
 http://bugs.python.org/issue1294032
 
 I think I would get too many (to me irrelevant) mails if I subscribe
 to the bug-automake mailing list.

Sure.  It's not too high traffic though.

Cheers,
Ralf

debbugs, and a FAQ, for Autotools

[Ralf Wildenhues]

[ Cross post; Reply-To and Mail-Followup-To set.  Please followup to
  the automake list only, to avoid excessive spammage.  Thank you.  ]

Hello everyone,

I've been advertising debbugs before, I think we should be a good
example.  So, two proposals:

1) Autoconf and Libtool should also use debbugs.

bug-automake has switched a few months ago, and I find it helpful to
avoid losing reports.  Given that we never have enough time on our
hands, it becomes more important to not lose track.

See http://debbugs.gnu.org/ and linked pages for details.

2) Autotools should have a FAQ document.  Not of the sort of the FAQ
chapter that answers seven random questions and that has a 1 year+
latency until it is updated, but one that answers both totally-newbie
kinds of questions that get asked over and over again, or cross-tool
bug questions like the infamous libtool echo problem (which was due to
an incompatible m4sugar change).  A document that, ideally, eventually
obsoletes many of the third-party here's how autotools work, in quick
kinds of pages.

See e.g., this most recent thread which made the need so clear again:
http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672


For (2) I'd suggest a wiki if we GNU the infrastructure, but something
like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html
would certainly be good.  (And yes, I've been arguing against wikis in
the past.  I was wrong.  Sue me.)


Now, I have very little spare time on my hands.  Any volunteers on
managing such a document?  Any people interested in contributing answers
or even only questions?  I wouldn't mind handing out commit privs to any
of the regulars on these lists.

Thanks for feedback,
Ralf

Re: $(srcdir)/foo is not generated because $(srcdir)/$(srcdir)/foo exists

[Peter Johansson]

Thanks Ralf for your quick reply,

On 2/13/11 2:44 AM, Ralf Wildenhues wrote:

I would prepend all lines of a rule with a TAB, not just those not
following a backslash-escaped newline.  I'm actually not totally sure
whether that was for portability to non-Posix make or so automake would
parse things reliably.



Thanks for your suggestions; I've implemented them.

else
## this is needed in 'svn export' build
$(srcdir)/.revision:
 echo   $@

I don't see why you should need this rule here.  The .revision file is
distributed, so it should already exist.  At most I'd add a stub target

   $(srcdir)/.revision:

here.  Maybe I'm missing something?



There are three ways you can get and build the package:

1) retrieve package.tar.gz and './configure; make'

2) svn checkout http://package.org/svn and do './bootstrap; ./configure; 
make'


Subversion provides a third way which is

3) svn export http://package.org/svn and do './bootstrap; ./configure; make'

The svn export command is a way to get what subversion refers to as a 
clean tree, i.e., only the files committed to the repository and no 
`.svn' directories with information about which revision which branch or 
anything. To be honest I'm not sure about the usefulness of this 
feature, but that discussion belongs elsewhere.


Anyway, in my case above: if a user chooses to 'svn export', file 
.revision is not there because it is not checked into the repository. 
And we can not use subversion to figure out what `.revision' since the 
tree holds no such information. Therefore, if we wanna support svn 
export builds we need to create the file `.revision' somehow although 
it cannot contain any useful information.


After sending my email yesterday I chose to move the creation of 
.revision to Autoconf time. That is if there is no .revision and no .svn 
directory I create a dummy .revision. This also removed my original 
problem referred to in the subject.


Thanks again,
Peter

Re: debbugs and (was: slow make clean)

[Glenn Morris]

Ralf Wildenhues wrote (on Sun, 13 Feb 2011 at 19:01 +0100):

 I glanced over the debbugs documentation at debbugs.gnu.org now, but
 couldn't find a place that said something about subscribing to
 individual bugs.  Glen, do you happen to know more about this?

I know that it doesn't work, and personally I don't know how to
implement it. :(

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439

Re: support for a program that compile files (like yacc or lex support)

[Vincent Torri]

ping 3 :)

On Mon, Jan 24, 2011 at 10:09 AM, Vincent Torri vincent.to...@gmail.comwrote:


 ping2 :)

 Vincent Torri

 On Tue, Jan 4, 2011 at 8:24 AM, Vincent Torri vto...@univ-evry.fr wrote:


 Hey,

 Wasn't what i want (see below) clear enough ?

 Vincent Torri

  First, it seems that i have deleted your answers while deleting other
 files. So I answer to my mail without your comments. Sorry for the
 inconvenience (the archive will not display this mail as an answer to your
 mail)

 On Mon, 20 Dec 2010, Vincent Torri wrote:

  * Vincent Torri wrote on Sat, Dec 18, 2010 at 08:52:59PM CET:

 I saw in the automake doc a support for yacc and lex. I looked in
 automake/am/ and saw 2 files, lex.am and yacc.am, which seem to
 allow that support.

 We have a program that tranforms .edc files into .edj files, and we
 would like to add similar support for that program.


 One input file, one output file?

 cat edc-rules.am EOF
 EDCC = edcc
 .edc.edj:
   $(EDCC) $(EDCFLAGS) -o $@ $
 EOF


 include edc-rules.am from each Makefile.am you want the rules in.


 That is what we are currently doing. A make rule.

  If that doesn't answer your question, please clarify what you want.


 I would like, in our Makefile.am, having something like:

 AM_EDCFLAGS = 
 bin_PROGRAMS = foo
 foo_SOURCES = bar.edc

 and automake will automatically use edcc to transform bar.edc into
 bar.edj

 See

 http://sources.redhat.com/automake/automake.html#Yacc-and-Lex
 http://git.savannah.gnu.org/cgit/automake.git/tree/lib/am/yacc.am
 http://sources.redhat.com/automake/automake.html#Python
 http://git.savannah.gnu.org/cgit/automake.git/tree/lib/am/python.am


 Also, as it is transforming a script file into a binary data file, I
 don't know if bin_PROGRAMS is what should be used. But I just saw that
 python support has rules like

 python_PYTHON = tree.py leave.py

 which is really what I would like to have. Having an 'EDJE' primary:

 AM_EDCFLAGS = edc_flags
 theme_EDJE = foo.edc

 then edcc would be called like that:

 edcc edc_flags foo.edc foo.edj

 Other things must be taken into account:

 * foo.edc must be in the tarball
 * installation path of foo.edj: what to do ? something like the DATA
  primary ?
 * adding prefix ?

 I hope I'm a bit clearer :)

 thank you

 Vincent Torri

Re: Test support for automake

[NightStrike]

On Sat, Feb 12, 2011 at 4:51 PM, Daily, Jeff A jeff.da...@pnl.gov wrote:
 From: automake-bounces+jeff.daily=pnl@gnu.org 
 [automake-bounces+jeff.daily=pnl@gnu.org] On Behalf Of Ralf Hemmecke 
 [hemme...@gmail.com]
 Sent: Friday, February 11, 2011 11:18 AM
 To: automake@gnu.org
 Subject: Test support for automake

 I have a non-recursive Makefile.am with which I build a library foo. I
 list all my tests (quite a lot) in check_PROGRAMS.

 All those tests should (of course) get libfoo.la as LDADD, but how
 exactly do I do that _without_ doing a per-target *_LDADD specification.
 Per target specification sounds like a lot of redundancy since all my
 _LDADD specification would just be libfoo.la.
 I'd like to add libfoo.la in only _one_ place.

 Ralf

 Use the LDADD variable.  It's similar to the AM_* variables e.g. AM_LDFLAGS, 
 AM_CPPFLAGS.  All programs use LDADD for linking unless it is overridden by a 
 maude_LDADD per-target variable.

 See http://sources.redhat.com/automake/automake.html#Linking

 Jeff





It sounds like this is a good use case for support of check_LDADD,
which of course is going to imply a request for generic x_Y support,
where x is any prefix (bin, lib, etc) and Y is any suffix (cflags,
etc).

Re: slow make clean

[Bob Friesenhahn]

On Sun, 13 Feb 2011, Ralf Hemmecke wrote:


I think I would get too many (to me irrelevant) mails if I subscribe to the 
bug-automake mailing list.


That is true, but you don't need to subcribe to the list in order to 
post to it and it is normal to be Cc:ed on any response.  A list 
moderator might need to bless the posting so that it goes through.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

bug#8031: feature request: slow make clean

[Ralf Hemmecke]

This is a copy of
http://lists.gnu.org/archive/html/automake/2011-02/msg00017.html
It's not really a bug, but rather a feature request.

Ralf

 Original Message 
Subject: slow make clean
Date: Sat, 12 Feb 2011 23:46:55 +0100
From: Ralf Hemmecke hemme...@gmail.com
To: automake@gnu.org

I've a project that must use subdir-objects, because of filename clashes 
in subdirectories (non-recursive build).


AM_INIT_AUTOMAKE([-Wall -Werror foreign subdir-objects])

I just have

lib_LTLIBRARIES = libfoo.la
check_PROGRAMS = ${TESTSUITE_TESTS} ${TESTSUITE_XFAIL_TESTS}

but quite a lot of files.

The generated Makefile contains a target mostlyclean-compile which has
about 1500 lines that look like

  -rm -f src/foo/foo.$(OBJEXT)
  -rm -f src/foo/foo.lo
  ...

Of course it takes ages to say make clean. About 10 sec.

Wouldn't it be faster if there were just one call to rm or at least
block the number of arguments to rm so that the maximal argument lenght
is not exceeded?

Any idea how I can speed that up?

Ralf

Re: turning off dependency tracking when building fat binaries on Mac OSX

[Peter Johansson]

Hi Ralf,

On 2/13/11 3:32 AM, Ralf Wildenhues wrote:

Yep.  I think that was one reason we explicitly documented the thing in
INSTALL.  With this configuration, your preprocessor will be wrong
(because CFLAGS are not passed to it) which means macro values may be
computed wrongly.

I'm not sure I understand what you mean here.

Do you suggest there is a difference between

./configure CFLAGS=-arch i386 -arch x86_64 LDFLAGS=-arch i386 -arch 
x86_64


and

./configure CC=-arch i386 -arch x86_64 CPP=gcc -E

Can you please explain. AFAICS, in both cases compilation and linking 
will occur with multiple archs but preprocessing will occur with a 
simple gcc -E

That doesn't mean we should break automake dependency tracking in this
configuration, but it does mean you shouldn't do it when it hurts.  ;-)

Sorry, but this is probably too many negations for me. Can you please 
explain.



You need to explicitly turn off dependency tracking. My question is
simply is there a good reason why automake does not turn off the
dependency tracking automagically in this case, or should I consider
it a missing feature.

I suppose I'll accept a patch that enhances automake/m4/depend.m4 to
address this.  Are you motivated?


Yes, I'm motivated. I've got some more time for free software so I think 
I could whip up a quick patch with the behavior I expect...


Cheers,
Peter