bug-make
[Top][All Lists]
Advanced

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

Idea of triggering bugs in users' Makefiles


From: Sergei Trofimovich
Subject: Idea of triggering bugs in users' Makefiles
Date: Fri, 4 Feb 2022 09:13:16 +0000

Individual developers more often than not build large projects
in parallel to speed the process up with 'make -j <something>'.

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 frequently forget that their
Makefile might be used in a 'make -j' setting and don't test
the scenario.

Recently I attempted to enable 'make -j $(nproc)' instead of
'make' for the whole NixOS software collection.

I found quite a few build failures. Most of them have very easy
fixes. The good simple example is 'cramfsswap':

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996964

There one of the targets uses effect of another target, but does
not declare it. Contrived example:

    # Makefile:
    all: a b
    a:
        touch a
    b:
        cp a b

Here 'make all' happens to work, but 'make b' alone does not.

This made me thinking: what could GNU make do to make these
types of errors more obvious?

I cane up with two ideas:

1. Enable parallel builds by GNU make by default, so 'make'
   would mean 'make -j $(nproc)' unless asked otherwise.

   Some build systems (like ninja or waf) already do it.
   While sounding drastic I think it's a reasonable change
   longer term.

2. Do not run dependencies in deterministic order by default:

   Even when make is ran sequentially GNU make could do some
   effort to reorder targets to have a higher chance of executing
   steps in unexpected order.

   A possible implementation would be to pick a random seed at
   GNU make startup and perform target order permutation when
   allowed. If build were to fail random seed would be printed
   along with failure message. That way it would be trivial for
   others to reproduce the failure. Sometimes build failures
   are very hard to replicate.

I think both are worth implementing.

What do you think? Would it be reasonable to implement any or
both of these changes for GNU make?

Thanks!

-- 

  Sergei



reply via email to

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