RFR: JDK-8072106 Properly handle dependencies for deleted header files
erik.joelsson at oracle.com
Thu Feb 5 11:44:40 UTC 2015
Looks good to me, but if it's possible, please split that huge echo
line. Adding a $$(strip ) will likely remove any extra white space
introduced by the split and indentation.
On 2015-02-04 13:23, Magnus Ihse Bursie wrote:
> 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
>>> 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.c \
>>> foo.h \
>>> foo-internal.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:
>>> (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