Обсуждение: Coming attractions: VPATH build; make variables issue

I've just successfully completed an out of the box VPATH build of
PostgreSQL (i.e., putting the object files in a different directory
structure than the source files).  It should be ready to go within the
next few days.

This is an opportune time to sort out the use of the make variables
CPPFLAGS and CFLAGS, which are used interchangeably in some places.  
Unfortunately, this would mean having to fix each of the targets

dep depend:$(CC) -MM $(CFLAGS) *.c >depend

(because the preprocessor options like -I and -D would be in CPPFLAGS).  
I can install a hook to make this work specially without need to fix each
file, but that would require GNU make 3.76 for those using `make depend'.  
I think this should not bother anyone too much, but I'm just letting you
know.  (Of course, `make depend' is obsolescent anyway.)

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> This is an opportune time to sort out the use of the make variables
> CPPFLAGS and CFLAGS, which are used interchangeably in some places.  
> Unfortunately, this would mean having to fix each of the targets

> dep depend:
>     $(CC) -MM $(CFLAGS) *.c >depend

Why?  Shouldn't CFLAGS include CPPFLAGS?  These targets seem correct
to me as they stand ... other than assuming CC is gcc, but nevermind
that...
        regards, tom lane

> (because the preprocessor options like -I and -D would be in CPPFLAGS).  
> I can install a hook to make this work specially without need to fix each
> file, but that would require GNU make 3.76 for those using `make depend'.  
> I think this should not bother anyone too much, but I'm just letting you
> know.  (Of course, `make depend' is obsolescent anyway.)

Looks like I have gmake 3.75 on BSD/OS 4.01:#$ gmake -vGNU Make version 3.75, by Richard Stallman and Roland
McGrath.Copyright(C) 1988, 89, 90, 91, 92, 93, 94, 95, 96        Free Software Foundation, Inc.This is free software;
seethe source for copying conditions.There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR APARTICULAR
PURPOSE.Reportbugs to <bug-gnu-utils@prep.ai.mit.edu>.
 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Tom Lane writes:

> > dep depend:
> >     $(CC) -MM $(CFLAGS) *.c >depend
> 
> Why?  Shouldn't CFLAGS include CPPFLAGS?

Nope.  That's what it does now, but the implicit rule is

%.o: %.c$(CC) -c $(CPPFLAGS) $(CFLAGS)

so if you set CFLAGS to include CPPFLAGS then you get all of it
double.  So I have to fix all the rules to say

dep depend:$(CC) -MM $(CPPFLAGS) $(CFLAGS) *.c >depend

I just notice that the workaround I had in mind won't work so well, so I
guess I'll have to fix it the hard way.


> These targets seem correct to me as they stand ... other than assuming
> CC is gcc, but nevermind that...

I'd be glad to add support for other compilers into the --enable-depend
mechanism, if someone supplies the details.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Tom Lane writes:

> > dep depend:
> >     $(CC) -MM $(CFLAGS) *.c >depend
> 
> Why?  Shouldn't CFLAGS include CPPFLAGS?  These targets seem correct
> to me as they stand ... other than assuming CC is gcc, but nevermind
> that...

Just a sanity check:  Does anyone use `make depend'?  Does everyone know
about the better way to track dependencies?  Does every-/anyone know why
`make depend' is worse?  I just don't want to bother fixing something
that's dead anyway...

(helpful reading: http://www.paulandlesley.org/gmake/autodep.html)

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

On Thu, 19 Oct 2000, Peter Eisentraut wrote:

> Tom Lane writes:
> 
> > > dep depend:
> > >     $(CC) -MM $(CFLAGS) *.c >depend
> > 
> > Why?  Shouldn't CFLAGS include CPPFLAGS?  These targets seem correct
> > to me as they stand ... other than assuming CC is gcc, but nevermind
> > that...
> 
> Just a sanity check:  Does anyone use `make depend'?  Does everyone know
> about the better way to track dependencies?  Does every-/anyone know why
> `make depend' is worse?  I just don't want to bother fixing something
> that's dead anyway...

Ummmm ... I don't *hangs head*  The only place I've ever really seen it
used extensively is the FreeBSD OS/kernel builds ...

Peter Eisentraut <peter_e@gmx.net> writes:
> Just a sanity check:  Does anyone use `make depend'?  Does everyone know
> about the better way to track dependencies?  Does every-/anyone know why
> `make depend' is worse?  I just don't want to bother fixing something
> that's dead anyway...
> (helpful reading: http://www.paulandlesley.org/gmake/autodep.html)

Well, you'll still have to touch every makefile :-( --- but I see no
good reason not to remove "make depend" if we have support for a better
solution.  Comments anyone?

One thought here: "make depend" has the advantage of being
non-intrusive, in the sense that you're not forced to use it and if
you don't use it it doesn't cost you anything.  In particular,
non-developer types probably just want to build from scratch when they
get a new distribution --- they don't want to expend cycles on making
useless (for them) dependency files, and they most certainly don't want
to be forced to use gcc, nor to install a makedepend tool.  I trust what
you have in mind doesn't make life worse for people who don't need
dependency tracking.
        regards, tom lane

Tom Lane writes:

> One thought here: "make depend" has the advantage of being
> non-intrusive, in the sense that you're not forced to use it and if
> you don't use it it doesn't cost you anything.  In particular,
> non-developer types probably just want to build from scratch when they
> get a new distribution --- they don't want to expend cycles on making
> useless (for them) dependency files, and they most certainly don't want
> to be forced to use gcc, nor to install a makedepend tool.

All of this is true for the "advanced" method as well.

The only advantage of `make depend' is that you can run it after you have
already built.  But then you have to remember to re-run it all the time,
otherwise the point of having accurate dependencies is gone.  So this
might be useful for someone installing a patch into a header file and not
wanting to rebuild from scratch, but that's about it.

What we could do is ship the dependencies (.deps/*.P) in the tarball.  
That would require running an entire build before making a tarball, but it
would be a nice service to users.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> What we could do is ship the dependencies (.deps/*.P) in the tarball.  
> That would require running an entire build before making a tarball, but it
> would be a nice service to users.

Hm.  It might be handy for people not using gcc, since they'd have no
easy way to build dependencies for themselves.  Do you have an idea
how much it'd bloat the tarball to do that?
        regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:  > What we could do is ship the dependencies (.deps/*.P) in the tarball.
 > That would require running an entire build before making a tarball, but it  > would be a nice service to users.
 
  Hm.  It might be handy for people not using gcc, since they'd have no  easy way to build dependencies for themselves.
Do you have an idea  how much it'd bloat the tarball to do that?
 

Isn't the basic idea to write Makefile targets to remake dependency
files when they are out of date with code?  Won't those targets
involve implicit rules for going, for example, from *.c -> *.d (or
whatever convention you use for dependency files)?  Don't these
Makefiles also have a list of srcs to be built, e.g., a make variable
that defines a list of *.c filename?

If so, can't you just implement a depend: target as
  ${DEPEND_FILES}+=${SRCS:%c=%d}  depend: ${DEPEND_FILES}  .SUFFIXES: .c .d  .c.d:gcc -M ...  .include
"${DEPEND_FILES}"

For gmake users, all the magic happens automatically.  Prior to
distribution, just do make depend to get all the *.d files to include
in the tarball.  For non-gmake users, all the *.d files already exist
in the source.  If they make changes, they can run make depend
manually.

Sorry if this is what you had in mind already, but the discussion
seemed to imply that you can't have it both ways.

Cheers,
Brook

Tom Lane writes:

> Do you have an idea how much it'd bloat the tarball to do that?
    current        deps        increase
gzipped        7.1 MB        35591 bytes    0.5%
unpacked    29MB        1309669 bytes    4%

Should be okay...

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/