automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with ansi2knr


From: Paul Smith
Subject: Re: Problems with ansi2knr
Date: 22 Oct 2002 18:38:38 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

%% Alexandre Duret-Lutz <address@hidden> writes:

  Paul> noinst_PROGRAMS = loadavg
  Paul> nodist_loadavg_SOURCES = loadavg.c
  Paul> loadavg_CFLAGS = -DTEST
  Paul> loadavg_LDADD = @GETLOADAVG_LIBS@

  Paul> loadavg.c: $(srcdir)/getloadavg.c
  Paul> cp $(srcdir)/getloadavg.c loadavg.c

  adl> (Incidentally, why do you copy the file instead of
  adl>    nodist_loadavg_SOURCES = getloadavg.c

Good idea... but see below.

  adl> The following patch should fix it.

OK, I tried automake 1.7.1 where this is fixed.  It does fix this
problem but unfortunately there are other problems lurking.

First, I tried it as you suggested above:

  noinst_PROGRAMS = loadavg
  nodist_loadavg_SOURCES = getloadavg.c
  loadavg_CPPFLAGS = -DTEST
  loadavg_LDADD = @GETLOADAVG_LIBS@

The fix you made did fix the problem I originally reported, but there
are still issues.  The above results in this in the output
Makefile/Makefile.in:

  loadavg-getloadavg$U.$(OBJEXT): getloadavg$U.c
    ...
  getloadavg_.c: getloadavg.c $(ANSI2KNR)
        $(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) 
$(CPPFLAGS) <...> | $(ANSI2KNR) > getloadavg_.c

Note there that the getloadavg_.c file is constructed using
CPP | ANSI2KNR, then the loadavg-*.o file is compiled directly from the
_.c.

This won't work because when we run the C preprocessor to create the
getloadavg_.c file we don't add in the $(loadavg_CPPFLAGS), so that
-DTEST is not defined.

Although we do add -DTEST in the compilation of _.c into _.o, by then
it's too late because during the ansi2knr-ification we already ran it
through the C compiler.  IOW, this is what automake does:

  cpp getloadavg.c | ansi2knr > getloadavg_.c

  cc $(loadavg_CPPFLAGS) getloadavg_.c -o loadavg-getloadavg_.o

  cc -o loadavg loadavg-getloadavg_.o

But we really want this instead:

  cpp getloadavg.c | ansi2knr > getloadavg_.c

  cpp $(loadavg_CPPFLAGS) getloadavg.c | ansi2knr > loadavg-getloadavg_.c

  cc loadavg-getloadavg_.c -o loadavg-getloadavg_.o

  cc -o loadavg loadavg-getloadavg_.o

Note how the ansi2knr is done twice, once to create an _.c file without
the loadavg_CPPFLAGS and _again_ to create a _different_ _.c file _with_
the loadavg_CPPFLAGS.


So, next thing I tried to do was to go back to my original work,
thinking that I could solve the problem by copying the original .c file
over, then automake would "ansi2knr" it for me and build a .o out of
that.  But, I found a slightly different bug here.  So I had this:

 noinst_PROGRAMS = loadavg
 nodist_loadavg_SOURCES = loadavg.c
 loadavg_CPPFLAGS = -DTEST
 loadavg_LDADD = @GETLOADAVG_LIBS@

 loadavg.c: $(srcdir)/getloadavg.c
        cp $(srcdir)/getloadavg.c loadavg.c

This seemed like it should work, and it did create the right rules for
me to convert loadavg.c into loadavg_.c, but it turns out that even in
this case the loadavg_CPPFLAGS were not included in the ansi2knr
statement; I conclude that even without the weird things I'm doing this
(adding a binary-specific set of preprocess flags) would never work with
ansi2knr.  When I try the above I get these commands:

  cp ./getloadavg.c loadavg.c

  cpp loadavg.c | ansi2knr > loadavg_.c

  cc $(loadavg_CPPFLAGS) loadavg_.c -o loadavg-loadavg_.o

  cc -o loadavg loadavg-loadavg_.o

Note again how the $(loadavg_CPPFLAGS) is missing from the CPP | ANSI2KNR 
line.  What I expected to get was this:

  cp ./getloadavg.c loadavg.c

  cpp $(loadavg_CPPFLAGS) loadavg.c | ansi2knr > loadavg_.c

  cc loadavg_.c -o loadavg-loadavg_.o

  cc -o loadavg loadavg-loadavg_.o


Thanks...

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden> HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]