We REALLY nead a NON-PCH build in JPRT NOW!
volker.simonis at gmail.com
Fri May 8 17:07:54 UTC 2015
On Fri, May 8, 2015 at 5:01 PM, Stefan Karlsson
<stefan.karlsson at oracle.com> wrote:
> On 2015-05-08 16:42, Volker Simonis wrote:
>> 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
>>>>> 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.
> Yes, I think you found that running without -fpch-deps was broken:
Oh my good - I completely forgot about this change!
I though about doing a 'hg annotate' before posting to see who
introduced it but than I forgot about it :)
So we should really check for the mentioned compiler bug before
dropping '-fpch-deps' in the new HotSpot build.
Thanks for the link,
More information about the hotspot-dev