Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Paul Smith wrote: > On Tue, 2023-01-17 at 01:38 +0900, KO Myung-Hun wrote: >> What I meant is checking the existence of a rule for a target not a >> real file built for a target. > > But how do you check for a "rule for a target"? > > What if the pattern rule is "%e" not "%.exe"? That will still match of > course. Or "%xe" or whatever? Or even "%o.exe"? Are we going to > check to find any possible pattern rule that might match a ".exe" and > behave differently if we find one, even if it has nothing to do with > actually creating a .exe file? GNU Make stops if it cannot find a target like: make: *** No rule to make target 'foo.exe'. Stop. I think, it's possible to use this logic in order to find a `foo.exe' target. And if it fails, check a `foo.exe' file in `foo' target. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
On Tue, 2023-01-17 at 01:38 +0900, KO Myung-Hun wrote: > What I meant is checking the existence of a rule for a target not a > real file built for a target. But how do you check for a "rule for a target"? What if the pattern rule is "%e" not "%.exe"? That will still match of course. Or "%xe" or whatever? Or even "%o.exe"? Are we going to check to find any possible pattern rule that might match a ".exe" and behave differently if we find one, even if it has nothing to do with actually creating a .exe file?
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Hi/2. Paul Smith wrote: > On Mon, 2023-01-16 at 22:14 +0900, KO Myung-Hun wrote: >>> But this does not seem like an easy thing to accomplish, at all. >>> What if there is a "%.exe" pattern rule, not an explicit rule for >>> "foo.exe"? >> >> I think, it's possible to do so by finding a target as GNU Make finds >> dependencies. > > GNU Make doesn't try to resolve all the targets including all implicit > targets first, then after they're all done try to build them. > > Instead, it tries to build every target as it is needed. So if you try > to build "foo.exe" first and it finds an implicit target "%.exe" then > you try to build "foo" second, it will see that the target "foo.exe" > already exists. > > But if you try to build "foo" first before "foo.exe", then there will > be no target "foo.exe" yet because you haven't tried to build it, and > it won't be found. Note here the "foo.exe" has to be intermediate of > course, otherwise it will be known to make even using an implicit rule. What I meant is checking the existence of a rule for a target not a real file built for a target. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
On Mon, 2023-01-16 at 22:14 +0900, KO Myung-Hun wrote: > > But this does not seem like an easy thing to accomplish, at all. > > What if there is a "%.exe" pattern rule, not an explicit rule for > > "foo.exe"? > > I think, it's possible to do so by finding a target as GNU Make finds > dependencies. GNU Make doesn't try to resolve all the targets including all implicit targets first, then after they're all done try to build them. Instead, it tries to build every target as it is needed. So if you try to build "foo.exe" first and it finds an implicit target "%.exe" then you try to build "foo" second, it will see that the target "foo.exe" already exists. But if you try to build "foo" first before "foo.exe", then there will be no target "foo.exe" yet because you haven't tried to build it, and it won't be found. Note here the "foo.exe" has to be intermediate of course, otherwise it will be known to make even using an implicit rule.
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Hi/2. Paul Smith wrote: > On Mon, 2023-01-16 at 00:15 +0900, KO Myung-Hun wrote: >> Then, this patch is acceptable? Or MSYS is a special case ? > > I don't think this patch is a good idea. I said in my initial email: > >> I don't think I like this change. I understand its usefulness but in >> general make never tries to manipulate the target names like this. > > And I haven't changed my mind. > > Also I asked: > >> What do you do in situations where there are targets for BOTH "foo" >> and "foo.exe" in the makefile? Then when you want to build "foo" it >> may decide that it's up to date, because it sees the "foo.exe" file >> instead. > > and you replied: > >> In this case, Make should not find "foo.exe" for "foo" target. > > But this does not seem like an easy thing to accomplish, at all. What > if there is a "%.exe" pattern rule, not an explicit rule for "foo.exe"? I think, it's possible to do so by finding a target as GNU Make finds dependencies. > It seems like this behavior would be very confusing for users, where > sometimes you would get one behavior and sometimes another, based on > what other rules did or didn't exist. > > The real problem here is that GCC is behaving in an unusual way, where > you ask it to generate an output file with one name and instead it > generates an output file with a different name. My opinion is that > this is a problem or an issue for GCC, and that we should not attempt > to paper over that issue by making changes in GNU Make. Ok, and thanks for your explanation! -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
On Mon, 2023-01-16 at 00:15 +0900, KO Myung-Hun wrote: > Then, this patch is acceptable? Or MSYS is a special case ? I don't think this patch is a good idea. I said in my initial email: > I don't think I like this change. I understand its usefulness but in > general make never tries to manipulate the target names like this. And I haven't changed my mind. Also I asked: > What do you do in situations where there are targets for BOTH "foo" > and "foo.exe" in the makefile? Then when you want to build "foo" it > may decide that it's up to date, because it sees the "foo.exe" file > instead. and you replied: > In this case, Make should not find "foo.exe" for "foo" target. But this does not seem like an easy thing to accomplish, at all. What if there is a "%.exe" pattern rule, not an explicit rule for "foo.exe"? It seems like this behavior would be very confusing for users, where sometimes you would get one behavior and sometimes another, based on what other rules did or didn't exist. The real problem here is that GCC is behaving in an unusual way, where you ask it to generate an output file with one name and instead it generates an output file with a different name. My opinion is that this is a problem or an issue for GCC, and that we should not attempt to paper over that issue by making changes in GNU Make.
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Hi/2. Eli Zaretskii wrote: >> Date: Sun, 15 Jan 2023 00:57:56 +0900 >> From: KO Myung-Hun >> CC: bug-make@gnu.org >> >>> How do you mean "make of mingw does not require $(EXEEXT)"? AFAICT, >>> if the Makefile defines a target FOO, and there's a file FOO.exe that >>> is up to date wrt its dependencies, the MinGW Make will recompile >>> anyway, because it doesn't understand that linking FOO produces >>> FOO.exe. >>> >>> So I think MinGW and OS/2 are in the same wagon here. >> >> I've tested make v3.81 for i686-pc-msys shipped with msys. > > You are right about MSYS Make, but MSYS is not MinGW, and AFAIK the > patches to Make done by the (now defunct) MSYS team were not > contributed upstream, so we don't know what they changed. > > Note, however, that MSYS Make has other goals than MinGW: MSYS is > supposed to emulate Unix enough to allow use of unaltered Unix > Makefile's to build MinGW ports. So the issue that you are talking > about is an explicit goal for MSYS, more-or-less its raison d'être. > Thus, it is not surprising that MSYS does this. Then, this patch is acceptable? Or MSYS is a special case ? -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
> Date: Sun, 15 Jan 2023 00:57:56 +0900 > From: KO Myung-Hun > CC: bug-make@gnu.org > > > How do you mean "make of mingw does not require $(EXEEXT)"? AFAICT, > > if the Makefile defines a target FOO, and there's a file FOO.exe that > > is up to date wrt its dependencies, the MinGW Make will recompile > > anyway, because it doesn't understand that linking FOO produces > > FOO.exe. > > > > So I think MinGW and OS/2 are in the same wagon here. > > I've tested make v3.81 for i686-pc-msys shipped with msys. You are right about MSYS Make, but MSYS is not MinGW, and AFAIK the patches to Make done by the (now defunct) MSYS team were not contributed upstream, so we don't know what they changed. Note, however, that MSYS Make has other goals than MinGW: MSYS is supposed to emulate Unix enough to allow use of unaltered Unix Makefile's to build MinGW ports. So the issue that you are talking about is an explicit goal for MSYS, more-or-less its raison d'être. Thus, it is not surprising that MSYS does this.
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Hi/2. Eli Zaretskii wrote: >> Date: Sat, 14 Jan 2023 23:40:57 +0900 >> From: KO Myung-Hun >> CC: bug-make@gnu.org >> >>> Please describe the use case in detail. This situation exists on >>> other platforms, not just of OS/2, and we don't do anything like that >>> for those other targets, AFAIK. Instead, the Makefile should use >>> $(EXEEXT) or somesuch to account for the issue. I don't see why OS/2 >>> should be handled differently. But maybe I'm missing something. >>> >> >> Yes, I appended $(EXEEXT) if necessary for libiconv, coreutils, and so >> on. BTW, I had a question while doing that. Because only OS/2 required >> $(EXEEXT). Windows platform such as mingw also requires it, but until I >> appended, it had not been there. In practice, make of mingw does not >> require $(EXEEXT). > > How do you mean "make of mingw does not require $(EXEEXT)"? AFAICT, > if the Makefile defines a target FOO, and there's a file FOO.exe that > is up to date wrt its dependencies, the MinGW Make will recompile > anyway, because it doesn't understand that linking FOO produces > FOO.exe. > > So I think MinGW and OS/2 are in the same wagon here. I've tested make v3.81 for i686-pc-msys shipped with msys. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
> Date: Sat, 14 Jan 2023 23:40:57 +0900 > From: KO Myung-Hun > CC: bug-make@gnu.org > > > Please describe the use case in detail. This situation exists on > > other platforms, not just of OS/2, and we don't do anything like that > > for those other targets, AFAIK. Instead, the Makefile should use > > $(EXEEXT) or somesuch to account for the issue. I don't see why OS/2 > > should be handled differently. But maybe I'm missing something. > > > > Yes, I appended $(EXEEXT) if necessary for libiconv, coreutils, and so > on. BTW, I had a question while doing that. Because only OS/2 required > $(EXEEXT). Windows platform such as mingw also requires it, but until I > appended, it had not been there. In practice, make of mingw does not > require $(EXEEXT). How do you mean "make of mingw does not require $(EXEEXT)"? AFAICT, if the Makefile defines a target FOO, and there's a file FOO.exe that is up to date wrt its dependencies, the MinGW Make will recompile anyway, because it doesn't understand that linking FOO produces FOO.exe. So I think MinGW and OS/2 are in the same wagon here.
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Hi/2. Paul Smith wrote: > On Fri, 2023-01-13 at 22:27 +0900, KO Myung-Hun wrote: >> This pattern is usually used on UNIX. However, on OS/2, gcc creates >> foo.exe not foo when an extension is not present, and Make check foo >> only. Therefore Make tries to build foo whenever called. > > I don't think I like this change. I understand its usefulness but in > general make never tries to manipulate the target names like this. If > users want to create a file named "foo.exe" they should use that as the > target name. > > I get that it's super-annoying that when you ask GCC to build a file > named "foo" via "-o $@" it will actually create a file named "foo.exe" > instead, but I think that's something that makefile authors will have > to deal with, rather than make. > I agree. But as you said, it's true that it's far less burden to porters. > What do you do in situations where there are targets for BOTH "foo" and > "foo.exe" in the makefile? Then when you want to build "foo" it may > decide that it's up to date, because it sees the "foo.exe" file > instead. In this case, Make should not find "foo.exe" for "foo" target. I willing to modify my patch for this. Thanks! -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
Hi/2. Eli Zaretskii wrote: >> From: KO Myung-Hun >> Date: Fri, 13 Jan 2023 22:27:43 +0900 >> >> For example, >> >> foo: foo.c >> gcc $@ $< >> >> This pattern is usually used on UNIX. However, on OS/2, gcc creates >> foo.exe not foo when an extension is not present, and Make check foo >> only. Therefore Make tries to build foo whenever called. > > Please describe the use case in detail. This situation exists on > other platforms, not just of OS/2, and we don't do anything like that > for those other targets, AFAIK. Instead, the Makefile should use > $(EXEEXT) or somesuch to account for the issue. I don't see why OS/2 > should be handled differently. But maybe I'm missing something. > Yes, I appended $(EXEEXT) if necessary for libiconv, coreutils, and so on. BTW, I had a question while doing that. Because only OS/2 required $(EXEEXT). Windows platform such as mingw also requires it, but until I appended, it had not been there. In practice, make of mingw does not require $(EXEEXT). So I made this patch. > In general, settling for 'foo.exe' when the target is 'foo' can easily > cause false positives, so such a change should IMO not be introduced > without a serious discussion of the possible downsides and > regressions. I agree. Thanks! -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM Korean OS/2 User Community : http://www.os2.kr/
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
On Fri, 2023-01-13 at 22:27 +0900, KO Myung-Hun wrote: > This pattern is usually used on UNIX. However, on OS/2, gcc creates > foo.exe not foo when an extension is not present, and Make check foo > only. Therefore Make tries to build foo whenever called. I don't think I like this change. I understand its usefulness but in general make never tries to manipulate the target names like this. If users want to create a file named "foo.exe" they should use that as the target name. I get that it's super-annoying that when you ask GCC to build a file named "foo" via "-o $@" it will actually create a file named "foo.exe" instead, but I think that's something that makefile authors will have to deal with, rather than make. What do you do in situations where there are targets for BOTH "foo" and "foo.exe" in the makefile? Then when you want to build "foo" it may decide that it's up to date, because it sees the "foo.exe" file instead.
Re: [PATCH] Check .exe as well when a target does not exist on OS/2
> From: KO Myung-Hun > Date: Fri, 13 Jan 2023 22:27:43 +0900 > > For example, > > foo: foo.c > gcc $@ $< > > This pattern is usually used on UNIX. However, on OS/2, gcc creates > foo.exe not foo when an extension is not present, and Make check foo > only. Therefore Make tries to build foo whenever called. Please describe the use case in detail. This situation exists on other platforms, not just of OS/2, and we don't do anything like that for those other targets, AFAIK. Instead, the Makefile should use $(EXEEXT) or somesuch to account for the issue. I don't see why OS/2 should be handled differently. But maybe I'm missing something. In general, settling for 'foo.exe' when the target is 'foo' can easily cause false positives, so such a change should IMO not be introduced without a serious discussion of the possible downsides and regressions.
