Обсуждение: Makefiles don't seem to remember to rebuild everything anymore
In a fully-built source tree:
$ cd pgsql/src/backend/parser
$ make
make: Nothing to be done for `all'.
... okay so far ...
$ rm gram.o
rm: remove regular file `gram.o'? y
$ make
make: Nothing to be done for `all'.
WTF?
If I also remove objfiles.txt then make wakes up and remembers it's
supposed to do something.
I can reproduce this with both make 3.81 and 3.82, so I think it's a bug
in our makefiles not make. I don't immediately see where the problem
is though.
regards, tom lane
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit : > In a fully-built source tree: > > $ cd pgsql/src/backend/parser > $ make > make: Nothing to be done for `all'. > ... okay so far ... > $ rm gram.o > rm: remove regular file `gram.o'? y > $ make > make: Nothing to be done for `all'. > > WTF? A previous patch changed the ".SECONDARY" from an if() section to the main section of src/Makefile.global.in, thus this target is triggered by each 'make' call. === commit 1eb1dde (HEAD, refs/bisect/bad) Author: Peter Eisentraut <peter_e@gmx.net> Date: Wed Oct 31 23:33:35 2012 -0400 Have make never delete intermediate files automatically Several hacks in certain modes already thought this was abad idea, so just disable it globally. === So 'one' fix for this case of gram.o is to add gram.c to the .SECONDARY, like this in the parser/Makefile # scan is compiled as part of gram +.SECONDARY: gram.cgram.o: scan.c While it fixes the example, I wonder if we have to maintain each intermediate files in Makefiles like that.... I also am not sure why the .SECONDARY has been moved up in the Makefile.global.in (removing this target completely also fix the issue) Hope it helps you and Peter find the good fix. -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Cédric Villemain <cedric@2ndquadrant.com> writes:
> Le vendredi 14 d�cembre 2012 23:02:11, Tom Lane a �crit :
>> $ rm gram.o
>> rm: remove regular file `gram.o'? y
>> $ make
>> make: Nothing to be done for `all'.
>>
>> WTF?
> A previous patch changed the ".SECONDARY" from an if() section to the main
> section of src/Makefile.global.in,
Hm. I should have made clear that this isn't specific to gram.o ---
I also tried "rm analyze.o" and that didn't trigger any action either.
So it doesn't seem to be a case of the bison rule chain being
specifically at fault.
I do suspect that this was triggered by some fairly recent makefile
change, though, because I don't recall having seen anything as odd
as this until recently.
regards, tom lane
On Sat, Dec 15, 2012 at 9:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Cédric Villemain <cedric@2ndquadrant.com> writes: >> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit : >>> $ rm gram.o >>> rm: remove regular file `gram.o'? y >>> $ make >>> make: Nothing to be done for `all'. >>> >>> WTF? > >> A previous patch changed the ".SECONDARY" from an if() section to the main >> section of src/Makefile.global.in, > > Hm. I should have made clear that this isn't specific to gram.o --- > I also tried "rm analyze.o" and that didn't trigger any action either. > So it doesn't seem to be a case of the bison rule chain being > specifically at fault. > > I do suspect that this was triggered by some fairly recent makefile > change, though, because I don't recall having seen anything as odd > as this until recently. > I can confirm that this happens on Mac OSX as well. I tried a lot of things in the Makefiles to see why the object file is not automatically built even though objfiles.txt is clearly marked as dependent on the OBJS. What I found though that the change Cédric mentioned above might have indeed introduced the problem. So if I comment out .SECONDARY directive in Makefile.global, .o files are rebuilt properly. I saw following in the documentation "When a file is secondary, make will not create the file merely because it does not already exist, but make does not automatically delete the file." (link: ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html#SEC97) Not sure if the .o files are treated as secondary files though. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
On Sun, Dec 16, 2012 at 12:23 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > > "When a file is secondary, make will not create the file merely > because it does not already exist, but make does not automatically > delete the file." > (link: ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html#SEC97) > And here is another relevant info from http://www.gnu.org/software/make/manual/html_node/Special-Targets.html ".SECONDARY with no prerequisites causes all targets to be treated as secondary (i.e., no target is removed because it is considered intermediate)." Reading that along with the other comment explains what we are seeing with a .SECONDARY without any prerequisites. BTW I also tried with a very simple Makefile to rule out any roles that implicit rules might be playing. If I create a Makefile like below: final: sfinalcp sfinal final sfinal: qfinalcp qfinal sfinal qfinal:touch qfinal If I build fully and then remove file "sfinal", subsequent make will recreate that file. But if I add a ".SECONDARY:" target without any prerequisites, "sfinal" will not be recreated. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
On 12/15/12 11:23 AM, Tom Lane wrote: > Cédric Villemain <cedric@2ndquadrant.com> writes: >> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit : >>> $ rm gram.o >>> rm: remove regular file `gram.o'? y >>> $ make >>> make: Nothing to be done for `all'. >>> >>> WTF? > >> A previous patch changed the ".SECONDARY" from an if() section to the main >> section of src/Makefile.global.in, > > Hm. I should have made clear that this isn't specific to gram.o --- > I also tried "rm analyze.o" and that didn't trigger any action either. > So it doesn't seem to be a case of the bison rule chain being > specifically at fault. > > I do suspect that this was triggered by some fairly recent makefile > change, though, because I don't recall having seen anything as odd > as this until recently. I can see it in 9.1 but not in 9.0, but I haven't had the time to pinpoint the exact change. Although it's a bit odd, it's not really a problem, I think. If you want to rebuild analyze.o, you should write "make analyze.o". If you want to rebuild postgres, run make in src/backend, and analyze.o (or whatever) will be rebuilt.
On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > If you > want to rebuild postgres, run make in src/backend, and analyze.o (or > whatever) will be rebuilt. FWIW for me, make in src/backend fails with this: i686-apple-darwin11-llvm-gcc-4.2: parser/analyze.o: No such file or directory make: *** [postgres] Error 1 Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
On 12/17/2012 08:46 AM, Peter Eisentraut wrote: > On 12/15/12 11:23 AM, Tom Lane wrote: >> Cédric Villemain <cedric@2ndquadrant.com> writes: >>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit : >>>> $ rm gram.o >>>> rm: remove regular file `gram.o'? y >>>> $ make >>>> make: Nothing to be done for `all'. >>>> >>>> WTF? >>> A previous patch changed the ".SECONDARY" from an if() section to the main >>> section of src/Makefile.global.in, >> > > Although it's a bit odd, it's not really a problem, I think. If you > want to rebuild analyze.o, you should write "make analyze.o". If you > want to rebuild postgres, run make in src/backend, and analyze.o (or > whatever) will be rebuilt. > > > That's a pretty nasty violation of the POLA. If our leading developer thinks something about our build process is a problem, it's a problem. cheers andrew
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> If you
>> want to rebuild postgres, run make in src/backend, and analyze.o (or
>> whatever) will be rebuilt.
> FWIW for me, make in src/backend fails with this:
> i686-apple-darwin11-llvm-gcc-4.2: parser/analyze.o: No such file or directory
> make: *** [postgres] Error 1
Yes, I see the same, on both make 3.81 and 3.82. (BTW, you have to
remove the postgres executable, else make won't even try to rebuild it.)
IMO this is broken. It did not use to work like that, either.
I'm familiar with the behavior here because I frequently recompile
individual .o files (eg, to build them with nondefault -O settings)
and am in the habit of rm'ing the .o file afterwards to let things
go back to normal. They no longer do.
Having seen this, I now think .SECONDARY is broken across the board.
A case comparable to .o files with nondefault CFLAGS could be that
one manually edits gram.c (say, to inject some debugging code),
rebuilds, and later wants to revert to a standard build. Formerly
you'd just rm gram.c and things would be good. Now, it's quite
unobvious what would need to be removed to convince make to do what
it's contracted to do. If you didn't watch the rebuild step very
closely (or, heaven forbid, used make -s and didn't see anything),
you could waste a lot of time before realizing that make hadn't
done what it's supposed to.
regards, tom lane
Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit : > Pavan Deolasee <pavan.deolasee@gmail.com> writes: > > On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > >> If you > >> want to rebuild postgres, run make in src/backend, and analyze.o (or > >> whatever) will be rebuilt. > > > > FWIW for me, make in src/backend fails with this: > > i686-apple-darwin11-llvm-gcc-4.2: parser/analyze.o: No such file or > > directory make: *** [postgres] Error 1 > > Yes, I see the same, on both make 3.81 and 3.82. (BTW, you have to > remove the postgres executable, else make won't even try to rebuild it.) > > IMO this is broken. It did not use to work like that, either. > I'm familiar with the behavior here because I frequently recompile > individual .o files (eg, to build them with nondefault -O settings) > and am in the habit of rm'ing the .o file afterwards to let things > go back to normal. They no longer do. > > Having seen this, I now think .SECONDARY is broken across the board. > A case comparable to .o files with nondefault CFLAGS could be that > one manually edits gram.c (say, to inject some debugging code), > rebuilds, and later wants to revert to a standard build. Formerly > you'd just rm gram.c and things would be good. Now, it's quite > unobvious what would need to be removed to convince make to do what > it's contracted to do. If you didn't watch the rebuild step very > closely (or, heaven forbid, used make -s and didn't see anything), > you could waste a lot of time before realizing that make hadn't > done what it's supposed to. make does what it is supposed to do here IIUC. Then we may just want to move the .SECONDARY in an ifcase again (the .SECONDARY is still interesting) What was the consensus when Peter did the change ? -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Cédric Villemain <cedric@2ndquadrant.com> writes:
> Le lundi 17 d�cembre 2012 16:45:16, Tom Lane a �crit :
>> Having seen this, I now think .SECONDARY is broken across the board.
> make does what it is supposed to do here IIUC.
Well, it's behaving as documented, but what this means is we need to be
very wary of what contexts we can use .SECONDARY in. I'd just as soon
try to avoid using it at all --- my example with hand-edited gram.c
points out that even rather short dependency chains can have unexpected
misbehaviors if the intermediate files are marked .SECONDARY.
> What was the consensus when Peter did the change ?
It was an experiment, nothing more; or at least that's how I saw it.
regards, tom lane
Le lundi 17 décembre 2012 15:29:09, Andrew Dunstan a écrit : > On 12/17/2012 08:46 AM, Peter Eisentraut wrote: > > On 12/15/12 11:23 AM, Tom Lane wrote: > >> Cédric Villemain <cedric@2ndquadrant.com> writes: > >>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit : > >>>> $ rm gram.o > >>>> rm: remove regular file `gram.o'? y > >>>> $ make > >>>> make: Nothing to be done for `all'. > >>>> > >>>> WTF? > >>> > >>> A previous patch changed the ".SECONDARY" from an if() section to the > >>> main section of src/Makefile.global.in, > > > > Although it's a bit odd, it's not really a problem, I think. If you > > want to rebuild analyze.o, you should write "make analyze.o". If you > > want to rebuild postgres, run make in src/backend, and analyze.o (or > > whatever) will be rebuilt. > > That's a pretty nasty violation of the POLA. If our leading developer > thinks something about our build process is a problem, it's a problem. That's not so obvious. The current behavior is expected by .SECONDARY. In other words, if I just 'touch rewriteDefine.c' then rewriteDefine.o will be rebuilt by make (as expected). $ touch rewriteDefine.c $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno- strict-aliasing -fwrapv -fexcess-precision=standard -I../../../src/include - D_GNU_SOURCE -c -o rewriteDefine.o rewriteDefine.c touch objfiles.txt It is maybe better to do a special case when you want to force rebuild, but in a more intuitive way than specifying each file you want to rebuild. Like that ?! : ==== diff --git a/src/Makefile.global.in b/src/Makefile.global.in index 9cc14da..8597792 100644 --- a/src/Makefile.global.in +++ b/src/Makefile.global.in @@ -31,8 +31,10 @@ all:# started to update the file..DELETE_ON_ERROR: +ifndef NOTSECONDARY# Never delete any intermediate files automatically..SECONDARY: +endif ==== $ rm rewriteDefine.o $ make nothing to do ... $ NOTSECONDARY=1 make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno- strict-aliasing -fwrapv -fexcess-precision=standard -I../../../src/include - D_GNU_SOURCE -c -o rewriteDefine.o rewriteDefine.c touch objfiles.txt -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Le lundi 17 décembre 2012 17:42:04, Tom Lane a écrit : > Cédric Villemain <cedric@2ndquadrant.com> writes: > > Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit : > >> Having seen this, I now think .SECONDARY is broken across the board. > > > > make does what it is supposed to do here IIUC. > > Well, it's behaving as documented, but what this means is we need to be > very wary of what contexts we can use .SECONDARY in. I'd just as soon > try to avoid using it at all --- my example with hand-edited gram.c > points out that even rather short dependency chains can have unexpected > misbehaviors if the intermediate files are marked .SECONDARY. "touch gram.c" then "make" will build again the affected files. Which is different from "rm gram.c"... A "touch gram.y" will trigger a rebuild of "gram.c" (and "gram.o"). Maybe Makefile has an option to be a little bit more conservative and rebuild any removed intermediate file even if not required. > > What was the consensus when Peter did the change ? > > It was an experiment, nothing more; or at least that's how I saw it. ok. -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
On Mon, Dec 17, 2012 at 10:19 PM, Cédric Villemain <cedric@2ndquadrant.com> wrote: > > That's not so obvious. > The current behavior is expected by .SECONDARY. > In other words, if I just 'touch rewriteDefine.c' then rewriteDefine.o will be > rebuilt by make (as expected). > > $ touch rewriteDefine.c > $ make > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- > statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno- > strict-aliasing -fwrapv -fexcess-precision=standard -I../../../src/include - > D_GNU_SOURCE -c -o rewriteDefine.o rewriteDefine.c Isn't that something very basic make is supposed to do anyways ? > touch objfiles.txt > > It is maybe better to do a special case when you want to force rebuild, but in > a more intuitive way than specifying each file you want to rebuild. > I don't understand what are we trying to achieve by doing what you did below. ISTM that the real problem is .SECONDARY without any prerequisites. If at all there are any files that we want to treat as secondary and not remove at the end, shouldn't we add them as prerequisites to this special target ? At least, that what I get reading man pages and samples. Thanks, Pavan > Like that ?! : > > ==== > diff --git a/src/Makefile.global.in b/src/Makefile.global.in > index 9cc14da..8597792 100644 > --- a/src/Makefile.global.in > +++ b/src/Makefile.global.in > @@ -31,8 +31,10 @@ all: > # started to update the file. > .DELETE_ON_ERROR: > > +ifndef NOTSECONDARY > # Never delete any intermediate files automatically. > .SECONDARY: > +endif > ==== > > $ rm rewriteDefine.o > $ make > nothing to do ... > $ NOTSECONDARY=1 make > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- > statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno- > strict-aliasing -fwrapv -fexcess-precision=standard -I../../../src/include - > D_GNU_SOURCE -c -o rewriteDefine.o rewriteDefine.c > touch objfiles.txt > > > -- > Cédric Villemain +33 (0)6 20 30 22 52 > http://2ndQuadrant.fr/ > PostgreSQL: Support 24x7 - Développement, Expertise et Formation -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
Cédric Villemain <cedric@2ndquadrant.com> writes:
> Le lundi 17 d�cembre 2012 17:42:04, Tom Lane a �crit :
>> Well, it's behaving as documented, but what this means is we need to be
>> very wary of what contexts we can use .SECONDARY in. I'd just as soon
>> try to avoid using it at all --- my example with hand-edited gram.c
>> points out that even rather short dependency chains can have unexpected
>> misbehaviors if the intermediate files are marked .SECONDARY.
> "touch gram.c" then "make" will build again the affected files.
Yes ... but still with the modified contents of gram.c, so this doesn't
solve the problem I described. I want make to regenerate the file in
question, not (only) its derived files.
regards, tom lane
On 12/17/12 8:46 AM, Peter Eisentraut wrote: > On 12/15/12 11:23 AM, Tom Lane wrote: >> Cédric Villemain <cedric@2ndquadrant.com> writes: >>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit : >>>> $ rm gram.o >>>> rm: remove regular file `gram.o'? y >>>> $ make >>>> make: Nothing to be done for `all'. >>>> >>>> WTF? >> >>> A previous patch changed the ".SECONDARY" from an if() section to the main >>> section of src/Makefile.global.in, >> >> Hm. I should have made clear that this isn't specific to gram.o --- >> I also tried "rm analyze.o" and that didn't trigger any action either. >> So it doesn't seem to be a case of the bison rule chain being >> specifically at fault. >> >> I do suspect that this was triggered by some fairly recent makefile >> change, though, because I don't recall having seen anything as odd >> as this until recently. > > I can see it in 9.1 but not in 9.0, but I haven't had the time to > pinpoint the exact change. The change happened here: [5c788e7cf5026be1cad634f12bb42111a411cd9e] When in automatic dependency mode, never delete any intermediate files automatically. I suppose that you are not using automatic dependency mode, so you are seeing the change just now with the recent introduction of global .SECONDARY. This is working correctly, as far as make is concerned. There is no configuration knob in make that says, build all the files you can think of even though they are not required for the target I gave you. If you are not happy with the current behavior, I suppose the best way forward would be to revert the global .SECONDARY setting and instead explicitly list the files you don't want deleted in localized .SECONDARY targets (something like .SECONDARY: gram.c). Needs some testing, of course.
Peter Eisentraut <peter@eisentraut.org> writes:
> I suppose that you are not using automatic dependency mode, so you are
> seeing the change just now with the recent introduction of global
> .SECONDARY.
True.
> This is working correctly, as far as make is concerned. There is no
> configuration knob in make that says, build all the files you can think
> of even though they are not required for the target I gave you.
Meh. I don't agree that parser/gram.o is "not required" when I'm asking
to build the postgres executable. The fact that making the latter
actually fails, as per Pavan's observation, should convince you of that
too.
Now perhaps this is not make's fault so much as a lack of adequate
dependency specifications. It may be that we can still use .SECONDARY
if we add the $(OBJS) lists as explicit targets of "make all" in backend
directories, but I'm not sure how invasive that would be.
regards, tom lane
I wrote:
> Now perhaps this is not make's fault so much as a lack of adequate
> dependency specifications. It may be that we can still use .SECONDARY
> if we add the $(OBJS) lists as explicit targets of "make all" in backend
> directories, but I'm not sure how invasive that would be.
I experimented a bit with this:
diff --git a/src/backend/common.mk b/src/backend/common.mk
index 2e56151..822b1e9 100644
*** a/src/backend/common.mk
--- b/src/backend/common.mk
*************** SUBDIROBJS = $(SUBDIRS:%=%/$(subsysfilen
*** 20,26 **** # top-level backend directory obviously has its own "all" target ifneq ($(subdir), src/backend)
! all: $(subsysfilename) endif SUBSYS.o: $(SUBDIROBJS) $(OBJS)
--- 20,26 ---- # top-level backend directory obviously has its own "all" target ifneq ($(subdir), src/backend)
! all: $(subsysfilename) $(OBJS) endif SUBSYS.o: $(SUBDIROBJS) $(OBJS)
which seems to fix the main issue, but it's still a bit wonky as far
as making objfiles.txt goes:
$ cd pgsql/src/backend/parser/
$ rm analyze.o
rm: remove regular file `analyze.o'? y
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I. -I.
-I../../../src/include-D_GNU_SOURCE -c -o analyze.o analyze.c
$ make
touch objfiles.txt
$ make
make: Nothing to be done for `all'.
This is definitely not per make's contract, either. I think maybe the
"Don't rebuild the list if only the OBJS have changed" hack in common.mk
is a brick or two shy of a load, but I don't know how to fix that.
regards, tom lane
On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Now perhaps this is not make's fault so much as a lack of adequate >> dependency specifications. It may be that we can still use .SECONDARY >> if we add the $(OBJS) lists as explicit targets of "make all" in backend >> directories, but I'm not sure how invasive that would be. > > I experimented a bit with this: > > diff --git a/src/backend/common.mk b/src/backend/common.mk > index 2e56151..822b1e9 100644 > *** a/src/backend/common.mk > --- b/src/backend/common.mk > *************** SUBDIROBJS = $(SUBDIRS:%=%/$(subsysfilen > *** 20,26 **** > > # top-level backend directory obviously has its own "all" target > ifneq ($(subdir), src/backend) > ! all: $(subsysfilename) > endif > > SUBSYS.o: $(SUBDIROBJS) $(OBJS) > --- 20,26 ---- > > # top-level backend directory obviously has its own "all" target > ifneq ($(subdir), src/backend) > ! all: $(subsysfilename) $(OBJS) > endif > > SUBSYS.o: $(SUBDIROBJS) $(OBJS) > > which seems to fix the main issue, but it's still a bit wonky as far > as making objfiles.txt goes: > > $ cd pgsql/src/backend/parser/ > $ rm analyze.o > rm: remove regular file `analyze.o'? y > $ make > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I. -I. -I../../../src/include-D_GNU_SOURCE -c -o analyze.o analyze.c > $ make > touch objfiles.txt > $ make > make: Nothing to be done for `all'. > > This is definitely not per make's contract, either. I think maybe the > "Don't rebuild the list if only the OBJS have changed" hack in common.mk > is a brick or two shy of a load, but I don't know how to fix that. I feel like it's been this way for a while - at least I feel like I've noticed this before. I think there is some inevitable kludginess around having one makefile per subdirectory that leads to these kinds of issues. Maybe we should get rid of all the makefiles under src/backend except for the top-level one and just do everything there. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> This is definitely not per make's contract, either. I think maybe the >> "Don't rebuild the list if only the OBJS have changed" hack in common.mk >> is a brick or two shy of a load, but I don't know how to fix that. > I feel like it's been this way for a while - at least I feel like I've > noticed this before. I think there is some inevitable kludginess > around having one makefile per subdirectory that leads to these kinds > of issues. Maybe we should get rid of all the makefiles under > src/backend except for the top-level one and just do everything there. I mentioned this paper last year, but maybe it's time to start taking it seriously: http://aegis.sourceforge.net/auug97.pdf regards, tom lane
On Wed, Dec 19, 2012 at 12:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> This is definitely not per make's contract, either. I think maybe the >>> "Don't rebuild the list if only the OBJS have changed" hack in common.mk >>> is a brick or two shy of a load, but I don't know how to fix that. > >> I feel like it's been this way for a while - at least I feel like I've >> noticed this before. I think there is some inevitable kludginess >> around having one makefile per subdirectory that leads to these kinds >> of issues. Maybe we should get rid of all the makefiles under >> src/backend except for the top-level one and just do everything there. > > I mentioned this paper last year, but maybe it's time to start > taking it seriously: > http://aegis.sourceforge.net/auug97.pdf +1 from me. I don't know that just fixing src/backend will do a whole lot to improve build times in and of itself, but I do think it might reduce the required amount of alchemy to keep things working. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company