Hi Mandy, Alan, Please find the proposal for CLI option of --strip-native-debug-symbols below.
On Fri, 2019-02-08 at 10:53 -0800, Mandy Chung wrote: > > On 2/8/19 2:08 AM, Alan Bateman wrote: > > I agree with Mandy that the CLI options need examination. The proposed > > `--strip-native-debug-symbols` seems reasonable but it will be > > inconsistent with the existing `--strip-debug` option. Mandy - what you > > would think about renaming the existing option to something that makes > > it clear that it strips the debug attribute from class files? (we would > > of course need to do something to keep the existing option working). > > Renaming it to make it clear is good. How about: > > --strip-debug-attribute > --strip-native-debug-symbols > > --strip-debug will invoke both --strip-debug-attribute and > --strip-native-debug-symbols, if supported. > > Typically we want to strip both. If only stripping debug attribute, > then it can use --strip-debug-attribute. > > What do you think? > > > The need to specify the argument as "defaults" or "options" is a bit > > annoying. It might be time to replace hasArguments in the plugin > > > interface to allow for optional arguments. > > Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin > accepts an optional argument. > > On the other hand, pluginToMaps will put an empty map if hasArguments > return false. The plugin processing code (PluginsHelper) is quite > complicated that I can't quite tell without spending time. > > In any case I think a plugin should support optional arguments. > > > The plugin interface is not > > exported/documented/supported so we have flexibility to change it. If we > > do this then it should mean the usages reduce down to: > > > > --strip-native-debug-symbols > > --strip-native-debug-symbols objcopy=<path-to-objcopy>:... > > objcopy is fine. > > It would also be nice to allow `keep-debuginfo` taking an optional > file extension. > > --strip-native-debug-symbols keep-debuginfo > --strip-native-debug-symbols keep-debuginfo=dbg The current implementation here has the following options: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ [i] --strip-native-debug-symbols defaults [ii] --strip-native-debug-symbols options:objcopy-cmd=<path/to/objcopycmd> [iii] --strip-native-debug-symbols options:debuginfo-file-ext=<ext> [iv] --strip-native-debug-symbols options:include-debug-syms=true The first option is a work-around for JDK-8218761. AFAIUI, fixing it will need rework of the Plugin interface and probably of the options parsing. Hence, I'd like to defer this post integration of the initial version of --strip-native-debug-symbols plugin. Cases [iii] and [iv] can be folded into one as suggested by Mandy with: --strip-native-debug-symbols keep-debuginfo --strip-native-debug-symbols keep-debuginfo=<ext> Case [ii] would become: --strip-native-debug-symbols objcopy=<path/to/objcopy> So in summary I'd propose these, where a) and b) may be combined, c) and a) or c) and b) combined would be an error: [a] --strip-native-debug-symbols keep-debuginfo[=<ext>] [b] --strip-native-debug-symbols objcopy=<path/to/objcopy> [c] --strip-native-debug-symbols defaults As a follow-up to an initial implementation of the above, I'd propose to hook it up with the current --strip-debug by a follow-up patch. It would first rename --strip-debug to --strip-debug-attribute or perhaps --strip-java-debug-symbols, and then let --strip-debug perform java and native debug symbols stripping as Alan suggested. Does that sound reasonable to you? Thanks, Severin