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: 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: 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.
