Re: Idea of triggering bugs in users' Makefiles

2022-02-07 Thread Edward Welbourne
David A. Wheeler (4 February 2022 17:43) wrote: > For example: When running each recipe, enable tracing > to note when files are opened for reading/writing. > If a recipe opens a file for reading (or presence?), and > that file isn't listed as a dependency but SHOULD be, warn about it. > E.g.,

Re: Idea of triggering bugs in users' Makefiles

2022-02-04 Thread Sergei Trofimovich
On Fri, 04 Feb 2022 10:27:01 -0500 Paul Smith wrote: > On Fri, 2022-02-04 at 09:13 +, Sergei Trofimovich wrote: > > 1. Enable parallel builds by GNU make by default > > > > 2. Do not run dependencies in deterministic order by default: > > GNU make (unlike Ninja) is bound by the POSIX

Re: Idea of triggering bugs in users' Makefiles

2022-02-04 Thread David A. Wheeler
> On Feb 4, 2022, at 4:13 AM, Sergei Trofimovich wrote: > > Individual developers more often than not build large projects > in parallel to speed the process up with 'make -j '. > > OS distributions would also prefer to enable parallel builds > by default. But there is a problem of deciding

Re: Idea of triggering bugs in users' Makefiles

2022-02-04 Thread Paul Smith
On Fri, 2022-02-04 at 09:13 +, Sergei Trofimovich wrote: > 1. Enable parallel builds by GNU make by default > > 2. Do not run dependencies in deterministic order by default: GNU make (unlike Ninja) is bound by the POSIX standard in terms of its behaviors. The POSIX standard makes very clear

Idea of triggering bugs in users' Makefiles

2022-02-04 Thread Sergei Trofimovich
Individual developers more often than not build large projects in parallel to speed the process up with 'make -j '. OS distributions would also prefer to enable parallel builds by default. But there is a problem of deciding if it's safe to build a package in general. In small projects developers