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

[David Holmes]

On 21/04/2015 10:14 AM, Volker Simonis wrote:
> 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.

The default depends on platform. For solaris we never use PCH. For the 
other platforms I think we always do.

Simply switching the default just creates a different problem. Engineers 
will use PCH locally and so may encounter issues if PCH has not been 
tested at integration time.

I plan to fix this in JPRT by making a few configurations non-PCH.

David
-----

> 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
>>>>> -----------
>>>>>
>>
>>