plplot-devel

[Plplot-devel] automatic dependencies

[Geoffrey F. <fu...@ga...>]

Hello all,

Driven by desperation, I've begun to implement automatic dependency
generation for PLplot.  I've just committed some files, and I figure I
should give people a heads up.

I hope my changes today don't mess anyone up.  If anyone sees builds
failing as a result of these changes, please let me know ASAP so I can
work on repairing things.

The way it works is that I've redefined the implicit rules for
building .o's from .c's.  It used to just directly invoke the CC
macro, with flags.  Now it "calls" a macro named
compile-c-and-emit-deps.  This is only on Linux however.  All other
platforms, should, I believe, be completely unchanged by todays
commits. 

The purpose of this macro is to do just what it's name says.  It is to
compile a C file, and emit dependency info for it.  

Then comes the tricky part.  I've implemented an attempt to autodetect
gcc version 3.  That's because with GCC version 3, they introduced
some very  nice flags for dependency genration, which are very
convenient, way nicer than what you had to do before.  So, /if/ you
have gcc version 3, then we use the new flags, otherwise we just do
what we did before (which was just to compile the file, wtihout
actually emitting dependencies), in which case we also don't claim to
have automatic dependencies implemented yet.  I'll go back and fix the
gcc 2 vintage code to do dependencies later.  But for now, it is
supposed to just work.  Please let me know if you see otherwise.

That is to say, those of you using gcc 2.x.y, are supposed to see no
change, either good or bad, from today's commits. And anyone using gcc
3, on Linux, is supposed to be seeing new super cool, auto morphing
dependencies. 

There is one bizardom.  Somehow, when I I try to test this with "gcc
2.96", it seems to somehow think it has a gcc 3 even though it
doesn't, so it uses the new flags, but also, somehow mysteriously,
this "gcc 2.96" seems to implement the new flags in gcc 3.  I dunno,
its too strange, maybe I need a break to clear the cobwebs.

So, this is like a 50% confidence commit.  Works for me, hope it
doesn't screw anybody else up, let me know if it does.  I figure
that's okay in the post release era, and I'll try to manage quick
fixes for ahyone who complains.  Let me know.

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] automatic dependencies

[<fu...@ga...>]

I've fixed the auto deps support for Linux + old GCC strains.  Sorry
about the flase start.

At this point, it is my belief that:

1) Platforms other than Linux should see no change to prior behavior.
   ie, stale deps stored in objs.in are used, provide the appearance
   of dependency support, but mask out of date dependencies, resulting
   in trouble for developers on those platforms.

2) Linux with old GCC should see substantially improved behavior.
   Dependencies are now maintained along with the .o's, so are always
   up to date.

3) Linux with GCC 3+ sees best in class automatic dependency support,
   with a single GCC invocation producing both the .o and the .d
   files. 

All core and driver C files are covered.  x??c.c demos are covered.
tutor.c is not covered, and all f77 and C++ files are not covered.  

demos.in should be reformulated to use GNU pattern rules more
aggressively, and search for a way to fold tutor into the mix.

Shouldn't be too hard to support C++ source files for gcc 2/3, but I
won't be satisfied unless the soln handles KCC too.

Need to decide how to deal with non-Linux systems.  The old objs.in
thing is so much inferior to automorphing deps that I'd be personally
tempted to just toss objs.in, but I don't know how to implement
autodeps for every platform supported by PLplot at this time.  What do
other developers think about dropping objs.in, and just taking the
position that if someone wants deps for <their favorite platform>
then they should contribute code to define the dependency generation
step in the new compilation paradigm for their os/compiler choice, and
we'll integrate it.   ???

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] automatic dependencies

[Alan W. I. <ir...@be...>]

On Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> Hello all,
>
> Driven by desperation, I've begun to implement automatic dependency
> generation for PLplot.  I've just committed some files, and I figure I
> should give people a heads up.
>
> I hope my changes today don't mess anyone up.  If anyone sees builds
> failing as a result of these changes, please let me know ASAP so I can
> work on repairing things.
>

Will do....;-)

I made a clean checkout, then my usual

./configure --prefix=/usr/local/plplot --with-double --enable-dyndrivers
--enable-java --enable-gnome --enable-ntk > & ! configure.out

Could see no problems in configure.out so I then tried make

make >&! make.out.

Here is that file with the error.

cd tmp; make default
make[1]: Entering directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
gcc -c          -O    -I. -I/home/software/java/jdk1.2.2//include -I/home/software/java/jdk1.2.2//include/linux -I/usr/include/tcl8.3 -I/usr/include/tcl8.3/itcl-private/generic -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/lib/gnome-libs/include -I/usr/include/orbit-1.0 -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [pdfutils.o] Error 1
make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
make: *** [all] Error 2

For your convenience here is a wrapped version of that gcc line

gcc -c          -O
-I. -I/home/software/java/jdk1.2.2//include
-I/home/software/java/jdk1.2.2//include/linux
-I/usr/include/tcl8.3
-I/usr/include/tcl8.3/itcl-private/generic
-I/usr/include/gtk-1.2
-I/usr/include/glib-1.2
-I/usr/lib/glib/include
-I/usr/X11R6/include
-I/usr/include/gnome-1.0
-I/usr/lib/gnome-libs/include
-I/usr/include/orbit-1.0
-MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o

On my system the gcc version is as follows:
gcc -dumpversion
2.95.4

The working compile I did yesterday with the old plplot didn't have the
"-MD -MF .d.pdfutils -MP -c" part of the command so I assume it is
some aspect of that string of parameters that is causing the
problem for my gcc version 2.95.4.

As you alluded to in your message the configuration seems to be adding these
gcc-3.0 parameters to the gcc command line when my system only has 2.95.4.

Good luck in getting this problem straightened out.

Alan

Re: [Plplot-devel] automatic dependencies

[Geoffrey F. <fu...@ga...>]

Hi Alan,

Thanks for the prompt usage report.

Alan W. Irwin writes:
 > gcc -c          -O    -I. -I/home/software/java/jdk1.2.2//include -I/home/software/java/jdk1.2.2//include/linux -I/usr/include/tcl8.3 -I/usr/include/tcl8.3/itcl-private/generic -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/lib/gnome-libs/include -I/usr/include/orbit-1.0 -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
 > gcc: cannot specify -o with -c or -S and multiple compilations
 > make[1]: *** [pdfutils.o] Error 1
 > make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
 > make: *** [all] Error 2
 > 
 > For your convenience here is a wrapped version of that gcc line
 > 
 > gcc -c          -O
 > -I. -I/home/software/java/jdk1.2.2//include
 > -I/home/software/java/jdk1.2.2//include/linux
 > -I/usr/include/tcl8.3
 > -I/usr/include/tcl8.3/itcl-private/generic
 > -I/usr/include/gtk-1.2
 > -I/usr/include/glib-1.2
 > -I/usr/lib/glib/include
 > -I/usr/X11R6/include
 > -I/usr/include/gnome-1.0
 > -I/usr/lib/gnome-libs/include
 > -I/usr/include/orbit-1.0
 > -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
 > 
 > On my system the gcc version is as follows:
 > gcc -dumpversion
 > 2.95.4

?!?!  What the heck is 2.95.4?  Never heard of it.  And the release
page at gcc.gnu.org makes no mention of it.  Must be another Linux
dist vendor inventing gcc releases again like Red Hat did when they
christened a daily gcc snapshot "2.96" and started the whole debacle. 

Could you do me a favor and paste that line into your system, and try
editing it to find out what makes the error message go away?  Is the
problem the -M* options, or is it the multiple -c options, or is it
just the use of the -o (which would totally floor me).

 > The working compile I did yesterday with the old plplot didn't have the
 > "-MD -MF .d.pdfutils -MP -c" part of the command so I assume it is
 > some aspect of that string of parameters that is causing the
 > problem for my gcc version 2.95.4.
 > 
 > As you alluded to in your message the configuration seems to be adding these
 > gcc-3.0 parameters to the gcc command line when my system only has 2.95.4.

Mmm.  Sorry.  Could you look in lib_sh_linux.in near the top, where
the with_gcc3 business is, and telll me if you see how the shell code
is coming up with the wrong answer there?  When I try to duplicate the
stuff that's in $(shell ...) on my own xterm, it comes up with the
right answer, so I can't see how it would be getting it wrong inside make.  

Shell drives me bonkers.

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] automatic dependencies

[Alan W. I. <ir...@be...>]

On Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> Hi Alan,
>
> Thanks for the prompt usage report.
>
> Alan W. Irwin writes:
>  > gcc -c          -O    -I. -I/home/software/java/jdk1.2.2//include -I/home/software/java/jdk1.2.2//include/linux -I/usr/include/tcl8.3 -I/usr/include/tcl8.3/itcl-private/generic -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/lib/gnome-libs/include -I/usr/include/orbit-1.0 -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
>  > gcc: cannot specify -o with -c or -S and multiple compilations
>  > make[1]: *** [pdfutils.o] Error 1
>  > make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
>  > make: *** [all] Error 2
>  >
>  > For your convenience here is a wrapped version of that gcc line
>  >
>  > gcc -c          -O
>  > -I. -I/home/software/java/jdk1.2.2//include
>  > -I/home/software/java/jdk1.2.2//include/linux
>  > -I/usr/include/tcl8.3
>  > -I/usr/include/tcl8.3/itcl-private/generic
>  > -I/usr/include/gtk-1.2
>  > -I/usr/include/glib-1.2
>  > -I/usr/lib/glib/include
>  > -I/usr/X11R6/include
>  > -I/usr/include/gnome-1.0
>  > -I/usr/lib/gnome-libs/include
>  > -I/usr/include/orbit-1.0
>  > -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
>  >
>  > On my system the gcc version is as follows:
>  > gcc -dumpversion
>  > 2.95.4
>
> ?!?!  What the heck is 2.95.4?  Never heard of it.  And the release
> page at gcc.gnu.org makes no mention of it.  Must be another Linux
> dist vendor inventing gcc releases again like Red Hat did when they
> christened a daily gcc snapshot "2.96" and started the whole debacle.

I believe the .4 is just part of the Debian numbering scheme.
From their changelog, they are just following gcc CVS for 2.9.5 for
various snapshots.

>
> Could you do me a favor and paste that line into your system, and try
> editing it to find out what makes the error message go away?  Is the
> problem the -M* options, or is it the multiple -c options, or is it
> just the use of the -o (which would totally floor me).

If the "-MF .d.pdfutils -MP" part of the option string is dropped all is
well. Another way of saying this is you can add -MD and (the redundant) -c
to the normal compile command from yesterday, and it compiles without
complaint, but -MF and -MP options cause problems.


>
>  > The working compile I did yesterday with the old plplot didn't have the
>  > "-MD -MF .d.pdfutils -MP -c" part of the command so I assume it is
>  > some aspect of that string of parameters that is causing the
>  > problem for my gcc version 2.95.4.
>  >
>  > As you alluded to in your message the configuration seems to be adding these
>  > gcc-3.0 parameters to the gcc command line when my system only has 2.95.4.
>
> Mmm.  Sorry.  Could you look in lib_sh_linux.in near the top, where
> the with_gcc3 business is, and telll me if you see how the shell code
> is coming up with the wrong answer there?  When I try to duplicate the
> stuff that's in $(shell ...) on my own xterm, it comes up with the
> right answer, so I can't see how it would be getting it wrong inside make.

The lines in question from the Makefile are the following:

************
with_gcc := yes

ifeq ($(with_gcc),yes)
# Need to figure out if this is GCC version 3 or not.
gcc_major := $(shell gcc -v 2>&1 | grep version | \
			cut '-d ' -f 3 | cut -d. -f 1 )
gcc_v3 := $(shell expr $gcc_major \>= 3)

ifeq ($(gcc_v3),1)
define compile-c-and-emit-deps
$(CC) $(1) -MD -MF $(3:$(2).o=.d.$(2)) -MP -c $(2).c -o $(3)
endef
automatic_deps := yes
else
define compile-c-and-emit-deps
$(CC) $(1) -c $(2).c -o $(3)
endef
automatic_deps := not_yet
endif

else
# Define the simple forms.
endif

************

Under bash on my system:
gcc -v 2>&1 | grep version | cut '-d ' -f 3 | cut -d. -f 1
2

So that works okay.  Furthermore,

export gcc_major=2
echo $gcc_major
2
expr $gcc_major \>= 3
0

So that works as well.

I then echoed gcc_major right from the Makefile and it
was 2 as expected.  I then tried the same thing with gcc_v3 and
it was 1 which *was not expected* and which causes the problem.

I have no idea why gcc_v3 is being set to 1 rather than the expected zero.

>
> Shell drives me bonkers.

The shell command within Makefiles drives me crazy....;-)

To verify my problem set gcc_major to 2, and go from there. Good luck in
finding why gcc_v3 is being set to 1 rather than the expected 0 under these
circumstances (gcc_major == 2). I wondered if the backwards slash in expr
$gcc_major \>= 3 had to be escaped when it is in a Makefile but replacing by
\\ just caused a syntax error.

Alan

Re: [Plplot-devel] automatic dependencies

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > On Tue, 26 Feb 2002, Geoffrey Furnish wrote:
 > >  > On my system the gcc version is as follows:
 > >  > gcc -dumpversion
 > >  > 2.95.4
 > >
 > > ?!?!  What the heck is 2.95.4?  Never heard of it.  And the release
 > > page at gcc.gnu.org makes no mention of it.  Must be another Linux
 > > dist vendor inventing gcc releases again like Red Hat did when they
 > > christened a daily gcc snapshot "2.96" and started the whole debacle.
 > 
 > I believe the .4 is just part of the Debian numbering scheme.
 > >From their changelog, they are just following gcc CVS for 2.9.5 for
 > various snapshots.

Well, there is no official gcc 2.95.4, just as there is no official
gcc 2.96.  Red Hat really opened a can of worms when they decided to
declare their own "gcc release" from a daily snapshot.  If more Linux
dists are following this trend, I think its going to lead to (more)
trouble. 

 > > Could you do me a favor and paste that line into your system, and try
 > > editing it to find out what makes the error message go away?  Is the
 > > problem the -M* options, or is it the multiple -c options, or is it
 > > just the use of the -o (which would totally floor me).
 > 
 > If the "-MF .d.pdfutils -MP" part of the option string is dropped all is
 > well. Another way of saying this is you can add -MD and (the redundant) -c
 > to the normal compile command from yesterday, and it compiles without
 > complaint, but -MF and -MP options cause problems.

Thanks.

 > I then echoed gcc_major right from the Makefile and it
 > was 2 as expected.  I then tried the same thing with gcc_v3 and
 > it was 1 which *was not expected* and which causes the problem.
 > 
 > I have no idea why gcc_v3 is being set to 1 rather than the expected zero.

Turned out to be a quoting issue.

Re: [Plplot-devel] automatic dependencies

[Alan W. I. <ir...@be...>]

On Wed, 27 Feb 2002, Geoffrey Furnish wrote:

>  > I have no idea why gcc_v3 is being set to 1 rather than the expected zero.
>
> Turned out to be a quoting issue.

OK.  I checked out a clean copy and everything builds nicely now with
generation of .d.* files to hold the dependency information.

Thanks, Geoffrey, for this quick fix.

Alan