Lost in automatic dependencies

[Stephane Bortzmeyer]

It seems that my C program does not track dependencies. If I touch a
".h", nothing is recompiled.

I did *not* use "no-dependencies". Reading the FM, it seems I should
have automatic dependencies tracking but I do not have.

automake (GNU automake) 1.9.6
gcc 4.1.2 or 3.3.3
GNU Make 3.81

Re: Lost in automatic dependencies

[Ralf Wildenhues]

Hi Stephane,

* Stephane Bortzmeyer wrote on Wed, Mar 28, 2007 at 10:41:51PM CEST:
> It seems that my C program does not track dependencies. If I touch a
> ".h", nothing is recompiled.
> 
> I did *not* use "no-dependencies".

Hmm.  Please show the configure output around "checking dependency
style".  Please also show the setting of CCDEPMODE in the Makefile.
Please also show the bit of the Makefile.am where you specify the
C program and its sources.  (IOW, I'd like all the clues that I can
get.  ;-)

Cheers,
Ralf

Re: Lost in automatic dependencies

[Ralf Wildenhues]

* quoting myself:
> * Stephane Bortzmeyer wrote on Wed, Mar 28, 2007 at 10:41:51PM CEST:
> > It seems that my C program does not track dependencies. If I touch a
> > ".h", nothing is recompiled.
> > 
> > I did *not* use "no-dependencies".

More clues (sorry, hit the wrong key too early): does the Makefile in
question contain a line of the form
  include ./$(DEPDIR)/objectname.Po

and does the file .deps/objectname.Po exist, and what does it contain?

Cheers,
Ralf

Re: Lost in automatic dependencies

[Stephane Bortzmeyer]

On Wed, Mar 28, 2007 at 10:48:24PM +0200,
 Ralf Wildenhues <[EMAIL PROTECTED]> wrote 
 a message of 16 lines which said:

> Please show the configure output around "checking dependency style".

gcc version 3.3.3 (NetBSD nb3 20040520)
...
configure:19139: checking dependency style of cc
configure:19229: result: none
configure:19248: checking dependency style of g++
configure:19338: result: none

> Please also show the setting of CCDEPMODE in the Makefile.

CCDEPMODE = depmode=none

> Please also show the bit of the Makefile.am where you specify the C
> program and its sources.

bin_PROGRAMS = echoping
man_MANS = echoping.1
echoping_SOURCES = echoping.c error.c readline.c writen.c util.c http.c icp.c 
HTParse.c echoping.h icp.h HTParse.h smtp.c
pkginclude_HEADERS = echoping.h compilation.h
echoping_LDADD =
echoping_LDFLAGS = -export-dynamic

> does the Makefile in question contain a line of the form include
> ./$(DEPDIR)/objectname.Po

Yes

include ./$(DEPDIR)/HTParse.Po
include ./$(DEPDIR)/echoping.Po
...

>  does the file .deps/objectname.Po exist, and what does it contain?

% cat .deps/echoping.Po 
# dummy

Re: Lost in automatic dependencies

[Ralf Wildenhues]

* Stephane Bortzmeyer wrote on Wed, Mar 28, 2007 at 11:06:31PM CEST:
> On Wed, Mar 28, 2007 at 10:48:24PM +0200,
>  Ralf Wildenhues <[EMAIL PROTECTED]> wrote 
>  a message of 16 lines which said:
> 
> > Please show the configure output around "checking dependency style".
> 
> gcc version 3.3.3 (NetBSD nb3 20040520)
> ...
> configure:19139: checking dependency style of cc
> configure:19229: result: none
> configure:19248: checking dependency style of g++
> configure:19338: result: none

So that's where it goes bonkers.  All other clues are followups.  Next
round: How exactly was configure invoked (I suppose you didn't pass
--disable-dependency-tracking ;-), and could you show the configure.ac
up to AC_PROG_CXX?

If that doesn't provide good clues, then I'll probably need to see
configure output with `set -x' added somewhere before the depmode tests
(and `set +x' somewhere after, to avoid noise) and maybe even with `set
-x' added at the top of the depcomp script (the script is used by the
configure tests).  What version is the depcomp script anyway?

Cheers,
Ralf

Re: Lost in automatic dependencies

[Stephane Bortzmeyer]

On Wed, Mar 28, 2007 at 11:16:32PM +0200,
 Ralf Wildenhues <[EMAIL PROTECTED]> wrote 
 a message of 27 lines which said:

> How exactly was configure invoked

 ./configure --config-cache

> and could you show the configure.ac up to AC_PROG_CXX?

I did not invoke AC_PROG_CXX (there is no C++ in the code), I assume
libtool did it for me.

You can get the whole program from
ftp://ftp.internatif.org/pub/unix/echoping/echoping-6.0.0..tar.gz
which should be simpler :-)

> What version is the depcomp script anyway?

depcomp 2005-07-09.11
 

Re: Lost in automatic dependencies

[Ralf Wildenhues]

* Stephane Bortzmeyer wrote on Wed, Mar 28, 2007 at 11:33:16PM CEST:
> On Wed, Mar 28, 2007 at 11:16:32PM +0200,
>  Ralf Wildenhues <[EMAIL PROTECTED]> wrote 
>  a message of 27 lines which said:

> > and could you show the configure.ac up to AC_PROG_CXX?
> 
> I did not invoke AC_PROG_CXX (there is no C++ in the code), I assume
> libtool did it for me.

Yep.  Bug in Libtool 1.5.x.  Workaround until Libtool 2.x is out:


> You can get the whole program from
> ftp://ftp.internatif.org/pub/unix/echoping/echoping-6.0.0..tar.gz
> which should be simpler :-)

Thanks, that helps a bit.  Doesn't provide me with the verbose output
from your system, though, so please enclose AM_INIT_AUTOMAKE in `set
-x', `set +x' in configure.ac, add `set -x' as second line to depcomp,
run autoconf and configure.  Send output.  Thanks.

Cheers,
Ralf

Re: undefined macro

[John Darrington]

[ CCing to automake@gnu.org as this is an automake issue ]

I had similar problems after upgrading to automake-1.10, which
(because it wasn't available in Debian etch) I installed in /usr/local
whereas all the m4 macros were in /usr.

The solution I used was to create a file
/usr/local/share/aclocal/dirlist containing the single line

 /usr/share/aclocal

I don't think this solution is particularly neat, but it worked for
me.

J'


On Wed, Mar 28, 2007 at 04:08:30PM -0400, Jason Stover wrote:
 make -f Smake is failing to expand AM_INTL_SUBDIR.  I've been
 struggling with this problem for a while now.  My lack of
 understanding of aclocal and autoconf is hindering progress. So tell
 me if I have this straight:
 
 1. aclocal should copy the contents of m4/*.m4 and gl/m4/*.m4
into configure.ac.
 2. autoconf should read the macros defined in configure.ac, run
m4 on them, and place the results in configure.
 
 Is that right?
 
 Now here is the error:
 
 $ make -f Smake
 
 ...
 aclocal -I m4 -I gl/m4
 autoconf
 configure.ac:26: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
 m4/gettext.m4:362: AM_GNU_GETTEXT is expanded from...
 configure.ac:26: the top level
 configure:20777: error: possibly undefined macro: AM_INTL_SUBDIR
   If this token and others are legitimate, please use m4_pattern_allow.
   See the Autoconf documentation.
 *** Error code 1
 
 ...the problem is that I can see the macro defined in the m4 directory:
 
 $ grep AM_INTL_SUBDIR m4/*.m4 
 m4/gettext.m4:AC_REQUIRE([AM_INTL_SUBDIR])dnl
 m4/intl.m4:AC_DEFUN([AM_INTL_SUBDIR],
 
 ...so it looks like aclocal isn't including some necessary information in
 configure.ac. Is that right? 
 
 But before it choked, I saw this:
 
 ...
 Copying file m4/intl.m4
 ...
 
 Doesn't that mean aclocal copied the defun into configure.ac?
 
 A few details that might be relevant: I recently upgraded to the latest 
version
 of automake, and auto*, and aclocal. My system has BSD m4 in /usr/bin, and 
GNU
 m4 1.4.3 in /usr/local/bin.
 
 Any hints or section of relevant docs I should read? 
 
 -Jason
 
 
 ___
 pspp-dev mailing list
 pspp-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/pspp-dev

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




signature.asc
Description: Digital signature