We REALLY nead a NON-PCH build in JPRT NOW!

[Volker Simonis]

On Thu, Apr 23, 2015 at 1:42 AM, Coleen Phillimore
<coleen.phillimore at oracle.com> wrote:
>
> On 4/22/15, 3:57 AM, Andrew Haley wrote:
>>
>> On 22/04/15 03:01, Daniel D. Daugherty wrote:
>>>
>>> Personally, I like the idea of not adding any more new JPRT targets
>>> and reconfiguring to have fastdebug and/or debug builds run as non-PCH...
>>> It's a much simpler policy to explain:
>>>
>>>       If we support PCH builds with a particular toolset then product
>>>       builds default to PCH and non-product builds default to no-PCH.
>>
>> But the debug builds are used in development all the time.  It's
>> these that really benefit from PCH.
>
>
> I feel like PCH makes development slower.  I change a header file and all
> the files in the system are recompiled because it happens to be in the
> precompiled file.  I wouldn't miss it for debug mode.
>

While working on the new HotSpot build (in the build-infra project)
I've just realized the we are currently using the option '-fpch-deps'.

Citing from the gcc man-page: "When using precompiled headers, this
flag will cause the dependency-output flags to also list the files
from the precompiled header's dependencies.  If not specified only the
precompiled header would be listed and not the files that were used to
create it because those files are not consulted when a precompiled
header is used."

This actually means that a .cpp file which uses PCH will depend on all
the headers in the PCH-file while while it should actually only depend
an the header files it explicitly includes itself. So this is probably
the reason why with PCH the change of a single header unnecessarily
triggers the recompilation of most of the
.cpp files. That said we of course still have certain header which are
included in all compilation units so there's nothing we can make once
such a file is changed.


> Coleen
>
>>
>> Andrew.
>>
>