Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On Wed, Dec 19, 2012 at 12:22 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
Robert Haas robertmh...@gmail.com writes: On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On 12/15/12 11:23 AM, Tom Lane wrote: =?iso-8859-15?q?C=E9dric_Villemain?= ced...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On 12/17/2012 08:46 AM, Peter Eisentraut wrote: On 12/15/12 11:23 AM, Tom Lane wrote: =?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
Pavan Deolasee pavan.deola...@gmail.com writes: On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit : Pavan Deolasee pavan.deola...@gmail.com writes: On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut pete...@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 signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
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: =?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
Le lundi 17 décembre 2012 17:42:04, Tom Lane a écrit : =?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On Mon, Dec 17, 2012 at 10:19 PM, Cédric Villemain ced...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On 12/17/12 8:46 AM, Peter Eisentraut wrote: On 12/15/12 11:23 AM, Tom Lane wrote: =?iso-8859-15?q?C=E9dric_Villemain?= ced...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
Peter Eisentraut pe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On Sun, Dec 16, 2012 at 12:23 AM, Pavan Deolasee pavan.deola...@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: sfinal cp sfinal final sfinal: qfinal cp 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
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 pete...@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 a bad 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.c gram.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 signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Makefiles don't seem to remember to rebuild everything anymore
On Sat, Dec 15, 2012 at 9:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: =?iso-8859-15?q?C=E9dric_Villemain?= ced...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
