Thread: configure in snapshout == configure.in

configure in snapshout == configure.in

From
Zeugswetter Andreas SB
Date:
There is something busted in the snapshots, that leads to a wrong
configure file. The file is equal to configure.in (not autoconf'ed).
First noticed shortly before Christmas.

Andreas


Re: configure in snapshout == configure.in

From
Tom Lane
Date:
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> There is something busted in the snapshots, that leads to a wrong
> configure file. The file is equal to configure.in (not autoconf'ed).
> First noticed shortly before Christmas.

Last week I tried to do a "make clean" in some subdirectory that's
not cleaned by a toplevel clean -- I think it was doc/src/sgml, but it
might have been a contrib dir -- and make went absolutely nuts.  When
the dust settled I had a toplevel configure file that was identical to
configure.in, just like you describe, and I couldn't do anything because
make kept trying to re-execute configure before it would do anything else.

After I re-fetched a valid copy of configure, I couldn't replicate the
behavior, so I thought maybe I'd mistyped.  But if it's happening in the
snapshot build too, then something is rotten in the makefiles.

I've seen some other bizarre behavior from make lately, like failing to
rebuild utils/SUBSYS.o when some of the utils subdirectories contained
newer SUBSYS.o files.  Again, hard to replicate, but I've seen it.
I'm starting to wonder if our spiffy new makefiles are stressing any
buggy areas of gmake...

FWIW, I'm running GNU Make version 3.79.1, which is the latest release
last I checked.
        regards, tom lane


Re: configure in snapshout == configure.in

From
Peter Eisentraut
Date:
Tom Lane writes:

> Last week I tried to do a "make clean" in some subdirectory that's
> not cleaned by a toplevel clean -- I think it was doc/src/sgml, but it
> might have been a contrib dir -- and make went absolutely nuts.  When
> the dust settled I had a toplevel configure file that was identical to
> configure.in, just like you describe, and I couldn't do anything because
> make kept trying to re-execute configure before it would do anything else.

It's in contrib/rserv/Makefile

%: %.in       sed -e "s:_OBJWD_:$(libdir)/contrib:g" \           -e "s:_DLSUFFIX_:$(DLSUFFIX):g" \           -e
"s:@SQLDIR@:$(libdir)/contrib:g"\           -e "s:@BINDIR@:$(bindir):g" \           -e "s:@LIBDIR@:$(libdir)/contrib:g"
<$< > $@       chmod 775 $@
 

which also triggers in src/Makefile.global

$(top_builddir)/config.status: $(top_srcdir)/configure       cd $(top_builddir) && ./config.status --recheck

when configure.in is older than configure, which is not all that unlikely.

I guess the rule in rserv's makefile needs to be qualified better.

> I've seen some other bizarre behavior from make lately, like failing to
> rebuild utils/SUBSYS.o when some of the utils subdirectories contained
> newer SUBSYS.o files.  Again, hard to replicate, but I've seen it.
> I'm starting to wonder if our spiffy new makefiles are stressing any
> buggy areas of gmake...

I'm aware of that problem.  It's pretty easy to replicate actually, if you
touch a file two or more directories deep under src/backend you will get
an incomplete build.  I'm thinking that we should convert the
subdirectories' rules for building their subdirectories back to a straigh
for-loop and not the cuteness that the backend/Makefile tries to do to get
parallel make's working efficiently.  Eventually the solution would be to
put all the rules in one makefile and not rely on recursion at all, but
that's for another day's debate.

> FWIW, I'm running GNU Make version 3.79.1, which is the latest release
> last I checked.

... but not necessarily the best. :-(

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



Re: configure in snapshout == configure.in

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> when configure.in is older than configure, which is not all that unlikely.

Newer than, I think you meant.  Yes, that's quite possible just after a
"cvs update".

> I guess the rule in rserv's makefile needs to be qualified better.

Agreed.

>> FWIW, I'm running GNU Make version 3.79.1, which is the latest release
>> last I checked.

> ... but not necessarily the best. :-(

What do you recommend?  IIRC, I updated to this version because it fixed
a bug that was biting me in gmake 3.78.1.
        regards, tom lane


Re: configure in snapshout == configure.in

From
Peter Eisentraut
Date:
Tom Lane writes:

> >> FWIW, I'm running GNU Make version 3.79.1, which is the latest release
> >> last I checked.
>
> > ... but not necessarily the best. :-(
>
> What do you recommend?  IIRC, I updated to this version because it fixed
> a bug that was biting me in gmake 3.78.1.

3.76.1 works best for me.  3.79.1 is okay, especially since it has a
number of nice new features.  Everything in between is sheer folly.

The most annoying thing is that rule chains of the form

all: foo.so

%.so: %.o$(LD) ...

# implicit %.o: %.c here

broke after 3.76.1 and have not been repaired.  (I'm not sure exactly what
the cause is as I have not been able to reproduce this with a dummy
makefile, but it probably has something to do with the fact that two
implicit rules are chained, with some other things interacting.)

When you first run 'make all' it will build foo.o and foo.so, then delete
foo.o because it's intermediate.  That's okay.  Then you run 'make all'
again (or perhaps via 'make install'), it will notice the missing foo.o
file and rebuild it and foo.so.  That's stupid.

Now I figured that I could avoid the deleting of the intermediate file
altogether by mentioning the target .SECONDARY:, but that will break in
3.78 if the %.c file is itself build from somewhere.  In that case it will
just bark with "not rule to make foo.c" or so.

You can see me cursing about this in the cvs logs, and this experience
made me install all the gmake versions I could find and try then regularly
when attempting something cute.  (So all recent gmake versions *should*
work with PostgreSQL, but I won't guarantee the corner cases.)

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