Re: Problems with configure after patch 123
Bram Moolenaar wrote: Tony Mechelynck wrote: The place of the include should not matter. The Makefile is first read completely before dependencies are followed. "distclean" does not depend on auto/config.mk. Perhaps your make program implies this dependency when including a file? I would call that a bug (some might call it a feature...). I'm using GNU make, version 3.80. From "info make", under "Include", I read the following (about two-thirds of the way down): [...] Once it has finished reading makefiles, `make' will try to remake any that are out of date or don't exist. *Note How Makefiles Are Remade: Remaking Makefiles. Only after it has tried to find a way to remake a makefile and failed, will `make' diagnose the missing makefile as a fatal error. [...] In this case, since there is a rule to make auto/config.mk, with auto/configure, config.mk.in and config.h.in as prerequisites, and one or more of the latter are newer than the included file config.mk, the latter is "an out-of-date makefile" and make tries to remake it -- by running configure. IOW this is a "documented feature" of GNU make. But I don't want to update auto/config.mk. I can understand that it's build when it does not exist, otherwise the only alternative is giving an error message and die. But when it exists it should be used as-is. I would rather call this a bug than a feature, I didn't specify the file should be updated. Isn't there a way to disable this "feature"? [...] Apparently the "make" philosophy is that one wants to use the most up-to-date makefiles possible. I'm not sure I understand fully from the make info text if and how you can avoid to remake an existing makefile if it's present but out-of-date. One method would of course be to drop the make rules for config.mk -- but what would happen when doing "make" the first time without a target? Another possibility would be to "touch" the config.mk file to make it newer than the rest -- but is it possible to do that other than manually? It says in the info text for make that a makefile target with two colons and no prerequisites will never be remade to avoid an endless loop (unlike a non-makefile target with two colons and no prerequisites, which is remade unconditionally IIUC). But double-colon rules are somewhat esoteric and I'm not sure whether this property is usable. Best regards, Tony.
Re: Problems with configure after patch 123
Tony Mechelynck wrote: > > The place of the include should not matter. The Makefile is first read > > completely before dependencies are followed. "distclean" does not > > depend on auto/config.mk. Perhaps your make program implies this > > dependency when including a file? I would call that a bug (some might > > call it a feature...). > > > > I'm using GNU make, version 3.80. From "info make", under "Include", I read > the following (about two-thirds of the way down): > > [...] > Once it has finished reading makefiles, `make' will try to remake any > that are out of date or don't exist. *Note How Makefiles Are Remade: > Remaking Makefiles. Only after it has tried to find a way to remake a > makefile and failed, will `make' diagnose the missing makefile as a > fatal error. > [...] > > In this case, since there is a rule to make auto/config.mk, with > auto/configure, config.mk.in and config.h.in as prerequisites, and one > or more of the latter are newer than the included file config.mk, the > latter is "an out-of-date makefile" and make tries to remake it -- by > running configure. IOW this is a "documented feature" of GNU make. But I don't want to update auto/config.mk. I can understand that it's build when it does not exist, otherwise the only alternative is giving an error message and die. But when it exists it should be used as-is. I would rather call this a bug than a feature, I didn't specify the file should be updated. Isn't there a way to disable this "feature"? > Since the include is in src/Makefile and not in vim70/Makefile, by > placing the "distclean" rule in the latter (explicitly, not as a call > to src/Makefile) we would avoid the include altogether, and thus the > check on whether the included makefile is out of date. "make distclean" should work in the "src" directory, like everything else. -- The startling truth finally became apparent, and it was this: Numbers written on restaurant checks within the confines of restaurants do not follow the same mathematical laws as numbers written on any other pieces of paper in any other parts of the Universe. This single statement took the scientific world by storm. So many mathematical conferences got held in such good restaurants that many of the finest minds of a generation died of obesity and heart failure, and the science of mathematics was put back by years. -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Problems with configure after patch 123
Bram Moolenaar wrote: Tony Mechelynck wrote: At patchlevel 125 (123-124-125 newly patched), "make reconfig" and "make distclean" both fail as follows (beware of "mailer beautification": all lines from GUI_INC_LOC= (included) to --enable-mzschemeinterp (excluded) end in a backslash): Starting make in the src directory. If there are problems, cd to the src directory and run make there I don't know how you start this, but you apparently didn't do "make distclean" in the "src" directory. I invoked it in the top directory, and the only rule it executed there was cd src && $(MAKE) $@ No variables set at that point. It's possible that when the timestamp of src/auto/configure changes the scripts get confused a bit. The current autoconf implementation isn't very user friendly when it comes to patching. I don't think I can do anything to avoid this. "make distclean" works fine for me and doesn't run configure first. It works fine for me too, _except_ when the configure source files have just been patched (as by patch 7.0.123) and the configure output files are older. I suspect the configure run happens because "make distclean" is trying to "make" the auto/config.mk which is to be "included" at line 289 of src/Makefile (note: "make" is a two-pass process). I suggest the "distclean" target rules (at least) be moved to the top Makefile in order to avoid including config.mk when making that target. The place of the include should not matter. The Makefile is first read completely before dependencies are followed. "distclean" does not depend on auto/config.mk. Perhaps your make program implies this dependency when including a file? I would call that a bug (some might call it a feature...). I'm using GNU make, version 3.80. From "info make", under "Include", I read the following (about two-thirds of the way down): [...] Once it has finished reading makefiles, `make' will try to remake any that are out of date or don't exist. *Note How Makefiles Are Remade: Remaking Makefiles. Only after it has tried to find a way to remake a makefile and failed, will `make' diagnose the missing makefile as a fatal error. [...] In this case, since there is a rule to make auto/config.mk, with auto/configure, config.mk.in and config.h.in as prerequisites, and one or more of the latter are newer than the included file config.mk, the latter is "an out-of-date makefile" and make tries to remake it -- by running configure. IOW this is a "documented feature" of GNU make. Since the include is in src/Makefile and not in vim70/Makefile, by placing the "distclean" rule in the latter (explicitly, not as a call to src/Makefile) we would avoid the include altogether, and thus the check on whether the included makefile is out of date. Best regards, Tony.
Re: Problems with configure after patch 123
Tony Mechelynck wrote: > >> At patchlevel 125 (123-124-125 newly patched), "make reconfig" and "make > >> distclean" both fail as follows (beware of "mailer beautification": > >> all lines from GUI_INC_LOC= (included) to --enable-mzschemeinterp > >> (excluded) end in a backslash): > >> > >> Starting make in the src directory. > >> If there are problems, cd to the src directory and run make there > > > > I don't know how you start this, but you apparently didn't do "make > > distclean" in the "src" directory. > > I invoked it in the top directory, and the only rule it executed there was > > cd src && $(MAKE) $@ > > No variables set at that point. > > > > > It's possible that when the timestamp of src/auto/configure changes the > > scripts get confused a bit. The current autoconf implementation isn't > > very user friendly when it comes to patching. > > > > I don't think I can do anything to avoid this. "make distclean" works > > fine for me and doesn't run configure first. > > > > It works fine for me too, _except_ when the configure source files have just > been patched (as by patch 7.0.123) and the configure output files are older. > > I suspect the configure run happens because "make distclean" is trying to > "make" the auto/config.mk which is to be "included" at line 289 of > src/Makefile (note: "make" is a two-pass process). I suggest the "distclean" > target rules (at least) be moved to the top Makefile in order to avoid > including config.mk when making that target. The place of the include should not matter. The Makefile is first read completely before dependencies are followed. "distclean" does not depend on auto/config.mk. Perhaps your make program implies this dependency when including a file? I would call that a bug (some might call it a feature...). -- The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases. For instance, the first phase is characterized by the question 'How can we eat?' the second by the question 'Why do we eat?' and the third by the question 'Where shall we have lunch?' -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Problems with configure after patch 123
Bram Moolenaar wrote: Tony Mechelynck wrote: At patchlevel 125 (123-124-125 newly patched), "make reconfig" and "make distclean" both fail as follows (beware of "mailer beautification": all lines from GUI_INC_LOC= (included) to --enable-mzschemeinterp (excluded) end in a backslash): Starting make in the src directory. If there are problems, cd to the src directory and run make there I don't know how you start this, but you apparently didn't do "make distclean" in the "src" directory. I invoked it in the top directory, and the only rule it executed there was cd src && $(MAKE) $@ No variables set at that point. It's possible that when the timestamp of src/auto/configure changes the scripts get confused a bit. The current autoconf implementation isn't very user friendly when it comes to patching. I don't think I can do anything to avoid this. "make distclean" works fine for me and doesn't run configure first. It works fine for me too, _except_ when the configure source files have just been patched (as by patch 7.0.123) and the configure output files are older. I suspect the configure run happens because "make distclean" is trying to "make" the auto/config.mk which is to be "included" at line 289 of src/Makefile (note: "make" is a two-pass process). I suggest the "distclean" target rules (at least) be moved to the top Makefile in order to avoid including config.mk when making that target. Best regards, Tony.
Re: Problems with configure after patch 123
Tony Mechelynck wrote: > At patchlevel 125 (123-124-125 newly patched), "make reconfig" and "make > distclean" both fail as follows (beware of "mailer beautification": all lines > from GUI_INC_LOC= (included) to --enable-mzschemeinterp (excluded) end in a > backslash): > > Starting make in the src directory. > If there are problems, cd to the src directory and run make there I don't know how you start this, but you apparently didn't do "make distclean" in the "src" directory. It's possible that when the timestamp of src/auto/configure changes the scripts get confused a bit. The current autoconf implementation isn't very user friendly when it comes to patching. I don't think I can do anything to avoid this. "make distclean" works fine for me and doesn't run configure first. -- Now it is such a bizarrely improbable coincidence that anything as mind-bogglingly useful as the Babel fish could have evolved purely by chance that some thinkers have chosen to see it as a final and clinching proof of the NON-existence of God. The argument goes something like this: 'I refuse to prove that I exist,' says God, 'for proof denies faith, and without faith I am nothing.' 'But,' says Man, 'the Babel fish is a dead giveaway, isn't it? It could not have evolved by chance. It proves you exist, and so therefore, by your own arguments, you don't. QED.' 'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a puff of logic. 'Oh, that was easy,' says Man, and for an encore goes on to prove that black is white and gets himself killed on the next pedestrian crossing. -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
