New hotspot build only builds "PRODUCT"

[Magnus Ihse Bursie]

On 2015-05-05 18:12, Volker Simonis wrote:
> On Tue, May 5, 2015 at 3:31 PM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2015-05-05 15:20, Volker Simonis wrote:
>>> Hi,
>>>
>>> I've just realized that the new hotspot build completely ignores the
>>> --with-debug-level configure settings and alwys build a release VM no
>>> matter how --with-debug-level was set.
>>>
>>> Is this a known limitiation?
>>> Do you currently concentrate on the realse build only?
>>
>> Yes and yes.
>>
>> Our current strategy is to get "equal builds" for products builds on "all"
>> platforms first, whatever hacks it might require. :) After that, we'll look
>> at cleaning up the code, and adding support for additional build features
>> like debug level.
>>
> OK, I see so I won't mess with debug builds then:)
Well, at some point we'll have to start supporting them, and since we do 
not yet have a pattern on how to do this, you might well start and 
introduce such a pattern if you want. :-) Hopefully, the only thing 
different for debug builds is the compiler flags.


> But another question: I just compared the dependencies compiler flags
> of the old and the new build and realized that for the old build we
> use '-MMD -MP -MF -fpch-deps' but in the new build we only use '-MMD
> -MF' (except for x86 which is the only platform in the new build where
> we still use -fpch-deps). Is this intentional as well?

I'm not speaking GCC flags fluently, but this sounds like the make 
dependency generation flags. There might be some differences there, yes. 
We get a bunch of flags "for free" from the build-infra framework. (You 
can see this if you do a SetupNativeCompilation with the CFLAGS argument 
empty.) This is flags that relate to the "infrastructure" aspect of the 
build, e.g. where to put the output file, and how to handle the make 
dependency files.

While having a similar or equal compiler command line between the old 
and new build is a good tool in ensuring we do things the same way, this 
is not an absolute goal. As long as the resulting binary is the same, 
there might be differences.

So, the question if this difference is "intentional". Yes and no. :-) We 
have not, intentionally, changed any flags, but we don't really care if 
these flags differ slightly, as long as it does not affect the result.

However, such differences can be worth noting anyway. It might be that 
the hotspot flags are "better" in some way. For instance, hotspot were 
using a flag (it might have been the -MP) that made the resulting 
dependency files declare the files themselves as targets. We emulate 
this behavior with sed instead, which works on all platforms, but are 
arguably less efficient when we have a gcc present that supports that flag.


>
> I think the omission of -MP may be related to "8072106: Properly
> handle dependencies for deleted header files" which created the
> corresponding targets manually.

... and maybe I should read the *whole* mail before starting to answer 
it. Yep, exactly. As I said above. :-)


> But what about '-fpch-deps', shouldn't we always use it?

Maybe. Perhaps even likely. I don't know what it does. Sounds like it's 
related to precompiled headers. We have not had precompiled header 
support before in the jdk native libraries, so this is new for the 
NativeCompilation framework. We might be missing some useful/neccessary 
flags here, yes.

/Magnus