Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[KO Myung-Hun]

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

[KO Myung-Hun]

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

[Eli Zaretskii]

> 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

[KO Myung-Hun]

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/

[bug #63639] Make syntax inconsistencies (perhaps old, no way to tell)

[Paul D. Smith]

Update of bug #63639 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

You are using a version which does not support these features.

GNU Make 3.81 was released in 2006 (17 years ago).  You should be reviewing
the documentation that came with the version of GNU Make you are using, not
the online documentation for the latest released version.

Assignment operators on define blocks were added in GNU Make 3.82.

Grouped targets were added in GNU Make 4.3.

You can view the GNU Make NEWS file online to see which features have been
added since GNU Make 3.81:

https://git.savannah.gnu.org/cgit/make.git/tree/NEWS


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63639] Make syntax inconsistencies (perhaps old, no way to tell)

[Paul D. Smith]

Follow-up Comment #2, bug #63639 (project make):

Just to note:

# Issue with grouped targets
target&: prereqs
#is not the same as
target &: prereqs
#The former works, the latter (with a space) tries to find a prereq called &

The comment at the end of this is not correct.

In GNU Make 3.81, the first rule *target&: prereqs* will cause make to try to
build a target named, literally, *target&* (you can see this by adding a
recipe that shows the value of the *$@* automatic variable).

The second rule *target &: prereqs* will declare _two_ targets: one named
*target* and one named *&*.  It won't "try to create a prereq called &".



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[Eli Zaretskii]

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

GNU Make 4.4.0.90 release candidate available

[Paul Smith]

GNU make is a tool which controls the generation of executables and
other non-source files of a program from the program's source files.

You can learn more at: https://www.gnu.org/software/make/


A new release candidate for GNU make 4.4.1 is available now for download:

  724e9144fa841bb1315aee1f2fd8e1d2  make-4.4.0.90.tar.lz
  09a2bb194655c99cd9eff23a9128df7f  make-4.4.0.90.tar.gz

You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

- NEWS 

Version 4.4.0.90 (14 Jan 2023)

This release is primarily a bug-fix release.
A complete list of bugs fixed in this version is available here:

https://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=110&set=custom

* WARNING: Backward-incompatibility!
  In previous releases it was not well-defined when updates to MAKEFLAGS made
  inside a makefile would be visible.  This release ensures they are visible
  immediately, even when invoking $(shell ...) functions.  Also, command line
  variable assignments are now always present in MAKEFLAGS, even when parsing
  makefiles.
  Implementation provided by Dmitry Goncharov 

* New feature: Parallel builds of archives
  Previously it was not possible to use parallel builds with archives.  It is
  still not possible using the built-in rules, however you can now override
  the built-in rules with a slightly different set of rules and use parallel
  builds with archive creation.  See the "Dangers When Using Archives" section
  of the GNU Make manual, and https://savannah.gnu.org/bugs/index.php?14927

* New platform: GNU Make is supported on z/OS
  Thanks to Igor Todorovski  for the patches and testing
  assistance.

* Previously target-specific variables would inherit their "export" capability
  from parent target-specific variables even if they were marked private.  Now
  private parent target-specific variables have no affect.  For more details
  see https://savannah.gnu.org/bugs/index.php?61463

* Updates to allow building on OS/2
  Provided by KO Myung-Hun 



signature.asc
Description: This is a digitally signed message part

Re: GNU Make 4.4.0.90 release candidate available

[Paul Smith]

On Sat, 2023-01-14 at 17:10 -0500, Paul Smith wrote:   
> 
>     GNU make is a tool which controls the generation of executables and
>     other non-source files of a program from the program's source files.
> 
>     You can learn more at: https://www.gnu.org/software/make/
>     
> 
> A new release candidate for GNU make 4.4.1 is available now for download:
> 
>   724e9144fa841bb1315aee1f2fd8e1d2  make-4.4.0.90.tar.lz
>   09a2bb194655c99cd9eff23a9128df7f  make-4.4.0.90.tar.gz
> 
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

I apologize for the above incorrect checksums... :(
Correct ones:

  11e16319a5013aa79777a98554707298  make-4.4.0.90.tar.lz
  b1f6757139afb569c024287d98bffb02  make-4.4.0.90.tar.gz



signature.asc
Description: This is a digitally signed message part

[bug #63667] In POSIX mode, the shell should not be run with -e if errors are ignored

[Vincent Lefèvre]

URL:
  

 Summary: In POSIX mode, the shell should not be run with -e
if errors are ignored
 Project: make
   Submitter: vinc17
   Submitted: dim. 15 janv. 2023 01:47:08
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: dim. 15 janv. 2023 01:47:08By: Vincent Lefèvre 
As said at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55025#24 (about an
issue with Automake) by Nick Bowler, when ".POSIX:" is used, GNU Make does not
conform to POSIX when errors are ignored. This affects commands like

  @-false; echo hello

where "hello" is not output because the shell is run with -e (the following
applies at least to GNU Make 4.3 and the Git current repository), which is
incorrect. Indeed, job.c contains:

  if (shellflags == 0)
shellflags = posix_pedantic ? "-ec" : "-c";

i.e. -e is always used in POSIX mode.

The POSIX standard[*] says:

"An execution line is built from the command line by removing any prefix
characters. Except as described under the at-sign prefix, the execution line
shall be written to the standard output, optionally preceded by a . The
execution line shall then be executed by a shell as if it were passed as the
argument to the system() interface, except that if errors are not being
ignored then the shell -e option shall also be in effect. If errors are being
ignored for the command (as a result of the -i option, a '-' command prefix,
or a .IGNORE special target), the shell -e option shall not be in effect. The
environment for the command being executed shall contain all of the variables
in the environment of make."

[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

If I understand correctly, errors are ignored if child->noerror or
ignore_errors_flag is true. So, in this case, -e should not be used.







___

Reply to this item at:

  

___
Message posté via Savannah
https://savannah.gnu.org/

[bug #63668] Default value of CXX on BSD OS's

[Brad Smith]

Additional Item Attachment, bug #63668 (project make):

File name: make_cxx.diff  Size:0 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/