[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David A. Wheeler
Subject: Re: Idea: Add command-line option for reporting potential makefile errors
Date: Wed, 12 Jun 2019 22:38:34 -0400 (EDT)

On Wed, 12 Jun 2019 16:02:15 -0400, Paul Smith <address@hidden> 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.
If it's something you have to separately install & invoke that's fine,
as long as it's *easy*.

However, it has to be *easy*.  The install must be no more than
"apt-get install make-audit" or "pip3 install make-audit" or similar.
Normal use must be no more than "make-audit [target]".
If it's any more complicated then that's a bug.  Nobody likes complicated
things for normal use cases.  It also needs to eventually handle make in
its full generality (e.g., if a user sets .ONESHELL to perl, it should still 

> I would be willing to work with people who wanted to implement such
> things as loadable modules in GNU make, to ensure that the loadable
> module API is enhanced in such a way that writing a module like this is
> feasible.  

As long as there's a mechanism that works easily that'd be great.

However, it's not clear to me that the hooks needed are easily available.
Also, the loadable modules stuff requires that I have a compiled object.
That's a big pain to set up & makes it difficult to create an
easy-to-install system across platforms.

I'd rather be able to simply call a program or shell script.
If I'm calling a command I'm already paying a price anyway.
In the short term I can abuse .ONESHELL and SHELL=, but that will struggle
wrapping Makefiles that already use .ONESHELL and SHELL=.

Would there be an appetite for a new Makefile variable that could specify
how to wrap a command about to be executed?
I haven't worked out the details, but that would make much
easier to wrap programs & would be very general.

> As DavidB pointed out, there are already project that attempt to
> provide some of these features

I took a look at his Poor Man's File Auditor 
It doesn't quite do what I want, but his approach looks like a *much* more
promising direction than using strace.

Instead of trying to use strace, pmaudit simply checks the atime & mtime
before & after execution.  That's extraordinarily portable (it even works on 
and FAR less fussy.  It can't monitor lstat & friends, but I think that's okay.
inotify can't notice lstats either, strace imposes a huge performance overhead, 
LD_PRELOAD is fussy & hard to keep up with (I know, I've done complicated 
things with it).
The pmaudit approach appears simple & rock-solid.

--- David A. Wheeler

reply via email to

[Prev in Thread] Current Thread [Next in Thread]