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

[Volker Simonis]

Hi Coleen,

the default is not to use PCH and I think that's probably OK for most
people. If somebody plays with the include files, he should use the
'--disable-precompiled-headers' configure option.

Making this option the default for the JPRT builds only will guard
against the build errors described before while it still allows
everybody to do local builds at full speed.

Regards,
Volker

On 4/21/15, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
> Can we just switch the default instead?  Is that a simple makefile change?
> Coleen
>
> On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote:
>> That would be great!!
>>
>> Thanks David,
>> Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 17. April 2015 12:23
>> To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn
>> Cc: HotSpot Open Source Developers
>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW!
>>
>> On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> another occurance of this ...  please, please add a non-pch build to
>>> jprt!
>>> https://bugs.openjdk.java.net/browse/JDK-8078048
>> I will. Unfortunately first I have some no-PCH issues to address. And
>> unfortunately they are not top of my priority list right now. Hopefully
>> next week sometime.
>>
>> David
>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
>>> Of Volker Simonis
>>> Sent: Donnerstag, 9. April 2015 11:35
>>> To: Andrew Dinn
>>> Cc: HotSpot Open Source Developers
>>> Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW!
>>>
>>> On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn <adinn at redhat.com> wrote:
>>>> On 09/04/15 09:02, Erik Joelsson wrote:
>>>>> I think that as long as we claim to support building both with and
>>>>> without PCH, the automatic testing should test both with and without
>>>>> PCH. By adding one or two build targets, or perhaps change an existing
>>>>> target, we could increase our test matrix to cover this easily.
>>>> I think this restates Volker's original remarks in redux.
>>>>
>>> No, not at all! I don't necessarily want to test more build
>>> configurations (that's another topic).
>>>
>>> My point is that PCH changes the compilation semantics and can hide
>>> real program errors. That's because with PCHs, every compilation unit
>>> sees the full precompiled header database (i.e. all the headers which
>>> are included in the "precompiled.hpp" PCH file). So if somebody
>>> forgets to include a dependency X.hpp in A.cpp, A.cpp may still
>>> compile with PCH because it includes the precompiled header file
>>> "precompiled.hpp" which in turn includes X.hpp. But the compilation of
>>> A.cpp will fail on platforms/configurations where we do not use
>>> precompiled headers. The two references I gave in my original mail are
>>> bugs that resulted from this problem.
>>>
>>> Besides program errors, the use of PCH can also lead to behavioral
>>> changes in the created binary when it comes to inlining. Because of
>>> PCHs some compilation units may be able to inline methods even if they
>>> do not explicitly include the files which contain the corresponding
>>> implementations because the implementation files are included in the
>>> PCH file. Without PCHs the compilers will simply emit calls to these
>>> functions (and, depending on the toolchain, emit a warning).
>>>
>>> I'm not familiar with ccache so I can not say if it has similar effects.
>>>
>>>> So, given that we do need this (NOW! :-) is anyone able and willing to
>>>> sponsor this?
>>>>
>>> Yes, this question remains to be answered :)
>>>
>>> Regards,
>>> Volker
>>>
>>>> regards,
>>>>
>>>>
>>>> Andrew Dinn
>>>> -----------
>>>>
>
>