Re: Idea: Add command-line option for reporting potential makefile errors

On Wed, 12 Jun 2019 16:02:15 -0400, Paul Smith wrote: > I get that having a make that "does everying right out of the box" is > seductive, but I'm not on board at this point. I actually don't care about whether or not it's "in the box" of make. I care about making it easy to perform the check.

[bug #56484] [RFE] compile modified files first

Follow-up Comment #2, bug #56484 (project make): > I don't think this could be an opt-out because make has a very longstanding expectation that prerequisites are built in left-to-right order (with -j1). Is it explicitly documented or just an implicit behavior? When I think of it: if the order

[bug #56484] [RFE] compile modified files first

Follow-up Comment #1, bug #56484 (project make): I don't think this could be an opt-out because make has a very longstanding expectation that prerequisites are built in left-to-right order (with -j1). ___ Reply to this item at:

[bug #56484] [RFE] compile modified files first

URL: Summary: [RFE] compile modified files first Project: make Submitted by: None Submitted on: Wed 12 Jun 2019 09:07:39 PM UTC Severity: 3 - Normal Item Group:

Re: Idea: Add command-line option for reporting potential makefile errors

On Tue, 2019-06-11 at 22:09 -0400, David A. Wheeler wrote: > Basically, when running a rule, make could enable strace to see > what is *actually* getting checked/read & written, compare that to > what the rule *claims* are the prerequisites & targets, and then > complain about differences. At

Re: Idea: Add command-line option for reporting potential makefile errors

On Wed, 12 Jun 2019 19:22:09 +0100, Tim Murphy wrote: > If you use strace to detect dependencies you might have to do a thorough > patent search. I will say no more because it's not my place to. The odds of an *enforceable* patent on strace seem extremely remote from the information I could

Re: Idea: Add command-line option for reporting potential makefile errors

In this context it might be worth mentioning two projects of mine, one simple/lightweight and the other complex and semi-abandoned. I will not describe them here in detail because the links do so. 1. Poor Man's File Auditor (https://github.com/boyski/pmaudit) This is a lightweight, unambitious,

Re: Idea: Add command-line option for reporting potential makefile errors

If you use strace to detect dependencies you might have to do a thorough patent search. I will say no more because it's not my place to. Regards Tim On Wed, 12 Jun 2019, 03:09 David A. Wheeler, wrote: > Problem: > > Makefiles often have errors, and they lay dormant because they're >

Re: Idea: Standard way to negate special targets

On Wed, Jun 12, 2019 at 7:25 PM David A. Wheeler wrote: > > I would strongly prefer "!" just binding to the next target & documenting > that. > The first time someone sees they may wonder how far it binds, > but it's pretty obvious that there are multiple possibilities, > so they can look it up

Re: Idea: Standard way to negate special targets

On Wed, 2019-06-12 at 12:25 -0400, David A. Wheeler wrote: > In addition, there's no obvious way to generalize that to > prerequisites in general. > Being able to remove prerequisites seems like something that > should be rarely used, but very useful when it is needed. > In particular, that'd

Re: Idea: Standard way to negate special targets

On Wed, 12 Jun 2019 11:59:50 -0400, Paul Smith wrote: > There's already too much whitespace-awareness in make as is IMO :). :-). > That's why I suggested embedding the "!" in the target name but if > people don't like that, then we should just document that the "!" binds > to the next target

Re: Idea: Standard way to negate special targets

On Wed, 2019-06-12 at 10:15 -0400, David A. Wheeler wrote: > > What about modifying the target name itself, like: > > > >tricky_target: .!ONESHELL .PHONY ... > > I think modifying the target name itself is MUCH worse. > > I don't the problem is serious, but I *do* see your point. > > I

Re: Idea: Standard way to negate special targets

On Wed, 12 Jun 2019 14:40:40 +0300, Michael Livshin wrote: > Or! > How about a general syntax for canceling prerequisites (not just for > special targets)? Say, "!:" (inspired by "&:")? > > Then you'd just say ".ONESHELL!: my-tricky-target". More verbose than > "my-tricky-target: ! .ONESHELL"

Re: Idea: Standard way to negate special targets

On Tue, 2019-06-11 at 16:25 -0400, David A. Wheeler wrote: > Add a syntax to *disable* a special target for > a particular rule. I propose that it be > a whitespace-surrounded "!" in the prerequisites > followed by the special target being disabled. E.g.: > > > .ONESHELL: > >

Re: Idea: Standard way to negate special targets

Or! How about a general syntax for canceling prerequisites (not just for special targets)? Say, "!:" (inspired by "&:")? Then you'd just say ".ONESHELL!: my-tricky-target". More verbose than "my-tricky-target: ! .ONESHELL" or whatever, but seems more robust to me (and more general, although I

Re: Idea: Standard way to negate special targets

David A. Wheeler (11 June 2019 22:25) wrote: >> I know of no other use for "!" in prerequisites. On June 12, 2019 4:42:15 AM EDT, Edward Welbourne wrote: >Well, it could be a file-name ;^> Fair enough, although I expect that to be extremely rare. That can be easily escaped as "./!". ---

Re: Idea: Standard way to negate special targets

David A. Wheeler (11 June 2019 22:25) wrote: > I know of no other use for "!" in prerequisites. Well, it could be a file-name ;^> For example, compare /usr/bin/[ A Unix could implement the shell's ! as an actual command. The make-file to build it would have ! as a target to build. The check rule