Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Geoff Clare via austin-group-l at The Open Group
Paul Smith wrote, on 04 Nov 2020: > > On Wed, 2020-11-04 at 16:47 +, Geoff Clare via austin-group-l at > The Open Group wrote: > > Here's a modified version of the proposed example that uses this new > > technique. Note that you have to use "make -r" otherwise it uses the > > default .c.o

[Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Austin Group Bug Tracker via austin-group-l at The Open Group
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To:

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Geoff Clare via austin-group-l at The Open Group
Joerg Schilling wrote, on 05 Nov 2020: > > Geoff Clare via austin-group-l at The Open Group > wrote: > > > The make utility shall use one of the following two methods > > to attempt to create the file or bring it up-to-date: > > > > 1. The "immediate remaking" method > > > > If

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Geoff Clare via austin-group-l at The Open Group
Paul Smith wrote, on 04 Nov 2020: > > On Wed, 2020-11-04 at 10:48 +, Geoff Clare via austin-group-l at > The Open Group wrote: > > The aim here was to describe the cut-off-point where all include file > > generation has been completed and after which the new contents of the > > files is used.

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Joerg Schilling via austin-group-l at The Open Group
Geoff Clare via austin-group-l at The Open Group wrote: > The make utility shall use one of the following two methods > to attempt to create the file or bring it up-to-date: > > 1. The "immediate remaking" method > > If make uses this method, any target rules or inference >

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Geoff Clare via austin-group-l at The Open Group
Paul Smith wrote, on 05 Nov 2020: > > On Thu, 2020-11-05 at 09:57 +, Geoff Clare via austin-group-l at > The Open Group wrote: > > > > The aim here was to describe the cut-off-point where all include > > > > file generation has been completed and after which the new > > > > contents of the

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Paul Smith via austin-group-l at The Open Group
On Thu, 2020-11-05 at 09:57 +, Geoff Clare via austin-group-l at The Open Group wrote: > > > The aim here was to describe the cut-off-point where all include > > > file generation has been completed and after which the new > > > contents of the files is used. This cut-off-point needs to be > >

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

2020-11-05 Thread Single UNIX Specification via austin-group-l at The Open Group
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02

[Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Austin Group Bug Tracker via austin-group-l at The Open Group
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To:

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Joerg Schilling via austin-group-l at The Open Group
Paul Smith via austin-group-l at The Open Group wrote: > On Thu, 2020-11-05 at 09:25 +, Geoff Clare via austin-group-l at > The Open Group wrote: > > That doesn't make any difference, since .c and .o are both in the > > specified suffixes, so that brings the default .c.o rule into play. > >

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Paul Smith via austin-group-l at The Open Group
On Thu, 2020-11-05 at 15:42 +, Geoff Clare via austin-group-l at The Open Group wrote: > > I agree we can't over-simplify but I don't see a problem with the > > specific case you mention. > > If the first target_name operand is the name of an include file that > needs to be created, your

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Paul Smith via austin-group-l at The Open Group
On Thu, 2020-11-05 at 09:25 +, Geoff Clare via austin-group-l at The Open Group wrote: > > .SUFFIXES: > > .SUFFIXES: .c .i .o > > > That doesn't make any difference, since .c and .o are both in the > specified suffixes, so that brings the default .c.o rule into play. Sorry, I didn't

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Paul Smith via austin-group-l at The Open Group
On Thu, 2020-11-05 at 19:36 +0100, Joerg Schilling wrote: > .SUFFIXES: > .SUFFIXES: .o .c > .c.o: > echo foo > > In other words, a users makefile has full control over the "builtin" > default rules even without a need to use "make -r". Sure, it's easy to redefine a suffix rule. The

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

2020-11-05 Thread Paul Smith via austin-group-l at The Open Group
On Thu, 2020-11-05 at 09:25 +, Geoff Clare via austin-group-l at The Open Group wrote: > That doesn't make any difference, since .c and .o are both in the > specified suffixes, so that brings the default .c.o rule into play. Hm. Right, I forgot that clearing the suffixes doesn't also delete