Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 statement "All include file regeneration is > complete before make attempts to bring [up-to-date] the > first target_name operand" creates a paradox. I don't really see a paradox here, sorry. Maybe I'm just not good enough at detailed reading. All include file generation is performed, then make attempts to bring the operands up to date. Why is there a paradox if an operand is also an include file? But I don't see a problem per se with the current wording so I'm happy to let this thread die as an academic discussion. Thanks Geoff!
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 issue in question was
that Geoff wanted to not use the .c.o rule at all. He wanted to use
other rules to build .o files in other ways, but the .c.o rule was
interfering with it. There's no way to DELETE that .c.o rule other
than -r.
However as I mentioned in my previous message you can still do it
without requiring -r, if you're very careful to order your suffixes
correctly so that the built-in .c.o rule is not considered.
> > In my opinion the -r option is wrong.
>
> Well GNU make makes the mistake to define pattern matching implicit
> rules in its default rules and this causes the following problems:
This is irrelevant to the topic at hand.
In fact, GNU make allows users to disable built-in rules completely
WITHOUT having to require users to add -r to the make command line,
because it allows users to add this to their makefile:
MAKEFLAGS += -r
and it does the right thing. Of course this is problematic as well
because that is now passed to sub-make invocations which may not be
what you want. However, in practice it is rarely a problem.
In fact, most of the built-in rules in GNU make ARE defined as suffix
rules; see this from default.c:
".c.o",
"$(COMPILE.c) $(OUTPUT_OPTION) $<",
".cc.o",
"$(COMPILE.cc) $(OUTPUT_OPTION) $<",
".C.o",
"$(COMPILE.C) $(OUTPUT_OPTION) $<",
".cpp.o",
etc.
However, GNU make also provides a number of built-in rules that cannot
be expressed as suffix rules, such as these:
/* RCS. */
{ "%", "%,v",
"$(CHECKOUT,v)" },
{ "%", "RCS/%,v",
"$(CHECKOUT,v)" },
{ "%", "RCS/%",
"$(CHECKOUT,v)" },
> - pattern matching rules have precedence over suffix rules and may
> themselves not be overwritten
>
> - pattern matching rules match in the order of their apperance to the
> parser. The first pattern rule that matches a specific pattern is
> used. Later specifying a replacement rule for a specific pattern is
> impossible.
>
> - The built in default rules must to be "read" by make before the
> users makefiles are parsed in order to allow them (the suffix
> rules) to be overwritten. Any pattern matching rule that appears
> in the builtin default rules thus would have precedence over
> anything else and cannot be overwritten.
Maybe these are problems in SunOS make / smake, but they are certainly
not problems in GNU make.
I'm not sure where the idea that pattern rules are immutable comes
from: in GNU make any pattern rule can be overwritten at any time,
including the default pattern rules.
Also, pattern rules can be completely canceled without overwriting
them, including as well the default pattern rules. It's just annoying
to have to do it by hand, and make sure you get them all, so something
like MAKEFLAGS += -r is much more robust.
Also, user-defined pattern rules are always added to be searched before
built-in pattern rules so the first one will always be a user-defined
pattern, if such exists.
And finally, it's not actually true that the first pattern rule that
matches is used. That used to be the case but quite a while ago the
pattern matcher was changed so that the rule with the shortest matching
stem is chosen first. If multiple pattern rules have stems with the
same length then the first one is chosen.
This algorithm change is a little controversial and I'm not sure about
it, but it seems to be acceptable in practice and it does avoid
worrying about the order in which patterns are defined.
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 read your example closely enough. Not only do you have to remove pre-existing suffixes, but you have to be very careful to order the suffixes correctly when you redefine them. I find the text in the standard somewhat confusing (particularly how when first introducing inference rules they are shown as ".s1.s2" but then a few paragraphs later this is changed to ".s2.s1"; if you miss that switch then the rest of the text doesn't make any sense). The order in which suffix rules are found depends on the order in which the suffixes appear in .SUFFIXES. To make your example work you need the order to be this: .SUFFIXES: .SUFFIXES: .o .i .c rather than ".c .i .o"... in particular you want the .c suffix to be after the .i suffix so that rules with .i are preferred.
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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. > > Hm. Right, I forgot that clearing the suffixes doesn't also delete the > rules. It's annoying that there's no POSIX way to delete the default > rules from within the makefile. There is no need to do that. In former times, there was no way to clear .SUFFIXES, but at that time, SunOS defined default rules that look this way: SUFFIXES= .o .c ... .SUFFIXES: $(SUFFIXES) so you could clear it by overwriting the SUFFIXES variable from your user makefile. Now POSIX requires that writing: .SUFFIXES: into a Makefile clears the suffix list and thus effectively disables all default implicit rules. If you only like the .c.o rule but are not happy with the builtin default rule for e.g. .c.o:, you can overwrite it by e.g. writing: .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". > In my opinion the -r option is wrong. Whether or not the default rules > should be used is a function of the _makefile_, not a function of the > _user_ of the makefile (the person who runs make). If the makefile is > written so that it doesn't want or need the default rules then the > makefile should be able to delete them. It shouldn't be up to the > invoker of make to do that. Well GNU make makes the mistake to define pattern matching implicit rules in its default rules and this causes the following problems: - pattern matching rules have precedence over suffix rules and may themselves not be overwritten - pattern matching rules match in the order of their apperance to the parser. The first pattern rule that matches a specific pattern is used. Later specifying a replacement rule for a specific pattern is impossible. - The built in default rules must to be "read" by make before the users makefiles are parsed in order to allow them (the suffix rules) to be overwritten. Any pattern matching rule that appears in the builtin default rules thus would have precedence over anything else and cannot be overwritten. For this reason, SunPro Make intentionally does not make use of pattern matching rules in the builtin default rules in order to permit the user to have full control over the behavior of make without a need to call "make -r". Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
[Issue 8 drafts 0001325]: Allow make to remake an included file
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5087 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-11-05 16:23 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review 2020-10-27 10:09 geoffclare Note Added: 0005070 2020-10-27 13:09 joerg Note Added: 0005071 2020-10-27 13:10 joerg Note Edited: 0005071 2020-10-27 14:04 psmith Note Added: 0005072 2020-10-27 14:36 psmith Note Added: 0005073 2020-10-27 15:24 joerg Note Added: 0005074 2020-10-27 15:26 joerg Note Edited: 0005074 2020-10-27 18:28 psmith Note Added: 0005075 2020-10-27 18:30 psmith Note Added: 0005076 2020-10-28 09:14 geoffclare Note Added: 0005077 2020-10-28 11:23 joerg Note Added: 0005078 2020-10-28 12:16 joerg Note Edited: 0005078 2020-10-28 13:47 psmith Note Added: 0005079 2020-10-28 14:44 geoffclare Note Added: 0005080 2020-10-28 14:49 psmith Note Added: 0005081 2020-10-28 14:50 psmith Note Added: 0005082 2020-10-28
Austin Group teleconference +1 888 974 9888 PIN 618 156 403
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 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:5fa4253931...@opengroup.org DTSTAMP:20201105T161553Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20201105T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 12-Nov-2020 at 11: 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n* All calls are anchored on US time **\n\nTopic: Austin Group teleconference\n--- \nAudio conference information \n---\n\nYou are invit ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n \nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +16465588656\, 618156403#\n\nPassword for zoom call ends with x\n\nAll Austin Group part icipants are most welcome to join the call.\nThe call will last for 90 min utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n \n\n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20201112T11 DURATION:PT1H30M0S LAST-MODIFIED:20201105T111553Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 files is used. This cut-off-point needs to be > > > > before make starts the "real work", i.e. starts the work to bring > > > > the first target operand, or the first target make encounters if > > > > there are no operands, up-to-date. > > > Can we just say that? All include file regeneration is complete > > > before make attempts to bring the first target_name operand, or the > > > first target make encounters if no target is specified? > > > > If we simplify it too much, it won't be correct. For example, > > consider the case where the first target_name operand is the name of > > an include file that needs to be created. > > 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 statement "All include file regeneration is complete before make attempts to bring [up-to-date] the first target_name operand" creates a paradox. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 > > > before make starts the "real work", i.e. starts the work to bring > > > the first target operand, or the first target make encounters if > > > there are no operands, up-to-date. > > Can we just say that? All include file regeneration is complete > > before make attempts to bring the first target_name operand, or the > > first target make encounters if no target is specified? > > If we simplify it too much, it won't be correct. For example, > consider the case where the first target_name operand is the name of > an include file that needs to be created. I agree we can't over-simplify but I don't see a problem with the specific case you mention. For GNU make, at any rate, nothing special will be done if a target_name operand is also an include file. The include file will be rebuilt (if needed) as usual, then make will attempt to build the target_name operand and realize it's already up to date, and go on to the next one (or finish).
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 the rules. It's annoying that there's no POSIX way to delete the default rules from within the makefile. In my opinion the -r option is wrong. Whether or not the default rules should be used is a function of the _makefile_, not a function of the _user_ of the makefile (the person who runs make). If the makefile is written so that it doesn't want or need the default rules then the makefile should be able to delete them. It shouldn't be up to the invoker of make to do that. And if the makefile is written so that it _does_ need the default rules, it shouldn't be up to the user to delete them with -r. Of course that's a completely separate topic :).
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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. This cut-off-point needs to be before make starts the > > "real work", i.e. starts the work to bring the first target operand, > > or the first target make encounters if there are no operands, up-to- > > date. > > Can we just say that? All include file regeneration is complete before > make attempts to bring the first target_name operand, or the first > target make encounters if no target is specified? If we simplify it too much, it won't be correct. For example, consider the case where the first target_name operand is the name of an include file that needs to be created. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[Issue 8 drafts 0001325]: Allow make to remake an included file
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-11-05 09:50 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == -- (0005100) geoffclare (manager) - 2020-11-05 09:50 https://austingroupbugs.net/view.php?id=1325#c5100 -- I have updated https://austingroupbugs.net/view.php?id=1325#c5087 based on comments here and on the mailing list. The changes are: Restructured the page 2892 change. Added "(unless the later include line is itself inside the dynamic include file)" in the second bullet in the page 2904 change. Improved wording in the page 2911 change (avoiding "gotchas"). Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review 2020-10-27 10:09 geoffclare Note Added: 0005070 2020-10-27 13:09 joerg Note Added: 0005071 2020-10-27 13:10 joerg Note Edited: 0005071 2020-10-27 14:04 psmith Note Added: 0005072 2020-10-27 14:36 psmith Note Added: 0005073 2020-10-27 15:24 joerg Note Added: 0005074 2020-10-27 15:26 joerg Note Edited: 0005074 2020-10-27 18:28 psmith Note Added: 0005075 2020-10-27 18:30 psmith Note Added: 0005076 2020-10-28 09:14
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 make uses this method, any target rules or inference > > rules for the pathname that were parsed before the include line > > was parsed shall be used to attempt to create the file or to > > bring it up-to-date before opening the file. > > > > 2. The "delayed remaking" method > > > > If make uses this method, no attempt shall be made to > > create the file or bring it up-to-date until after the > > makefile(s) have been read. During processing of the include > > line, make shall read the current contents of the file, > > if it exists, or treat it as an empty file if it does not exist. > > Once the makefile(s) have been read, make shall use any > > applicable target rule or inference rule for the pathname, > > regardless of whether it is parsed before or after the include > > line, when creating the file or bringing it up-to-date. > > Additionally in this case, [...] > > > > If the pathname is relative, [...] > > Sorry, but this would result in non-portable makefiles and it is not > acceptable. > > In order to permit portable makefiles, all rules to make/remake include files > need to be before the include statement. That's a constraint on applications, not on impelementations. It is covered by the first bullet point in the proposed APPLICATION USAGE addition. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 > rules for the pathname that were parsed before the include line > was parsed shall be used to attempt to create the file or to > bring it up-to-date before opening the file. > > 2. The "delayed remaking" method > > If make uses this method, no attempt shall be made to > create the file or bring it up-to-date until after the > makefile(s) have been read. During processing of the include > line, make shall read the current contents of the file, > if it exists, or treat it as an empty file if it does not exist. > Once the makefile(s) have been read, make shall use any > applicable target rule or inference rule for the pathname, > regardless of whether it is parsed before or after the include > line, when creating the file or bringing it up-to-date. > Additionally in this case, [...] > > If the pathname is relative, [...] Sorry, but this would result in non-portable makefiles and it is not acceptable. In order to permit portable makefiles, all rules to make/remake include files need to be before the include statement. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
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 rule instead! The rules for a.o and b.o seem to be > > needed by SunPro make but not by GNU make. > > > > .POSIX: > > .SUFFIXES: .c .i .o > > To avoid using make -r you can clear the suffixes before defining new > ones: > >.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. One way of handling the issue is to alert the user to the need to use -r if they forget: CC = echo "Please use make -r"; false (Of course, this means you can't use $(CC) in the specified rules, but my example uses c99 so it works there.) -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
