RFR: JDK-8072106 Properly handle dependencies for deleted header files

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Wed Feb 4 12:23:22 UTC 2015

On 2015-02-04 02:28, David Holmes wrote:
> On 3/02/2015 11:25 PM, Magnus Ihse Bursie wrote:
>> On 2015-02-02 23:14, David Holmes wrote:
>>> Hi Magnus,
>>> On 3/02/2015 1:51 AM, Magnus Ihse Bursie wrote:
>>>> When a header file is deleted, make will complain "No rule to make
>>>> target <old header file>". This often breaks incremental build
>>>> completely unnecessary.
>>> When/why would a header file be deleted?
>> Because it is not needed anymore? :-)
>> Ok, let's try to clarify this a bit. To support incremental compilation,
>> we generate (through compiler support or otherwise) a "make dependency
>> file" *.d for every *.o file we compile. This file is included in the
>> make file for the next run, and it basically looks like this (but with
>> full paths):
>> foo.o:
>>    foo.c \
>>    foo.h \
>>    foo-internal.h \
>>    utils.h
>> This means, that if say utils.h is modified, then foo.o gets rebuilt.
>> Great. That's the foundation of incremental builds.
>> However, if any of the files in this list is removed (or moved, which
>> amounts to the same thing, since they are in reality (but not my
>> example) stored with full paths), when make tries to look at the
>> timestamp for that file, it finds no file at all, so it tries to build
>> it, but cannot do that since there are no rules for it, and fails. By
>> adding "dummy" rules such as:
>> foo.c:
>> foo.h:
>> foo-internal.h:
>> utils.h:
>> (but with full paths)
>> then make has a "rule" for these files even if they don't exist, and
>> does not complain.
>> For a real-world example of the last time this happened, see the commit
>> last week by Erik when he moved files from the generic "unix" directory
>> to OS-specific directories such as "linux". Without this patch,
>> incremental builds were impossible after pulling that fix, and a make
>> clean was needed.
>> Any clearer?
> Okay but I really question the premise of attempting an incremental 
> build under such conditions :)

While we have not really had complete focus on it, the original goal of 
the build-infra system was that we should always succeed with 
incremental builds whenever possible. I believe this is a worthwile 
goal, and this patch is one step towards getting back on track to it.

I lost track a bit in the discussion here. Is the "okay" an ok from you 
as a reviewer?


More information about the build-dev mailing list