On 20/11/2015 2:15 AM, Omair Majid wrote:
* David Holmes <david.hol...@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
