RFR: JDK-8036003: Add --with-debug-symbols=[none|internal|external|zipped]

[David Holmes]

On 20/11/2015 2:15 AM, Omair Majid wrote:
> * David Holmes <david.holmes at oracle.com> [2015-11-18 07:01]:
>> My main point of contention is that zipping is simply a packaging choice for
>> the externally generated symbols - and we already have a configure option to
>> control that so I don't see why we would want to double up on that part. (I
>> don't think we have a deprecation policy for configure args.)
>
> There's a whole bunch of decisions related to debug information the
> build has to make:
>
> 1. Should debugging information be generated at all?
>
> Assuming yes:
>
> 2. Should the debug information be put in separate debug info flies?
>
> 3. Should the debug information be stripped from the original
> binaries?
>
> Assuming 2 is "yes":
>
> 4. Should the debug info files be zipped?
>
> So, yes, zipping is just one choice.

I'm well aware of all the above as per discussions from 2014.

My point with current proposal is that either it doesn't touch the 
zipping because we already have an option for that; or it should 
deprecate the existing option (now Erik has pointed out that capability).

David
-----

> The current options are not sufficient for us (the distribution
> packagers) because they don't cover our desired outcome which is:
>
> 1. Yes.
> 2. No.
> 3. No.
> 4. N/A.
>
> Currently, we have to rely on implementation details by calling make
> with a set of (implementation defined) flags which are subject to change
> within a single release since they are not officially defined at all.
>
> As an example, here's what the build instructions for Fedora look like:
>
> ./configure \
>    --disable-zip-debug-info
>
> make \
>      DEBUG_BINARIES=true \
>      JAVAC_FLAGS=-g \
>      STRIP_POLICY=no_strip \
>      STRIP="" \
>      ALT_OBJCOPY=none \
>
> Just to get what we want.
>
> Returning to your earlier point about zipping being one choice, we could
> fix this issue by adding flags for all other choices. However, that
> would make the build more complex and it's not clear that all choices
> are actually needed.
>
> So, the proposed patch offers a set of values that basically represent a
> set of choices in a more obvious way: they describe the end result and
> let the implementation decide how to achieve the result.
>
> Thanks,
> Omair
>