This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/16793] New: Exempt built-in tapsets from --compatible parsing changes
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 01 Apr 2014 20:14:59 +0000
- Subject: [Bug translator/16793] New: Exempt built-in tapsets from --compatible parsing changes
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16793
Bug ID: 16793
Summary: Exempt built-in tapsets from --compatible parsing
changes
Product: systemtap
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: jistone at redhat dot com
Blocks: 13664
When we make a change to the parser that also keeps its old behavior with some
--compatible option, we've essentially made a tiny fork in the language. That
puts our tapset code in a tight spot, where we must either stick to the least
common denominator of features, or alternate their syntax choice according to
systemtap_v conditionals. (Tapsets already use systemtap_v for their own
compatibility changes, but they shouldn't need to do so outside that.)
This proposal is that built-in tapsets should always be parsed with the current
syntax, no matter what the user's --compatible option is. This way tapsets can
freely make use of new features, like PR13664 types. Tapsets will still see
the chosen systemtap_v for their own compatibility conditions though.
SYSTEMTAP_TAPSET should be treated the same as built-in tapsets for this
purpose, since it overrides the built-in. However, -I paths should be parsed
under --compatible just as the primary user script is, so a user trying to run
an old collection of code can still do so.
If a third-party distro package installs files into the main tapset path, those
will have to be prepared for new syntax. I don't think this is a problem,
because such files would have previously been at the whim of --compatible
anyway, so now they too will have a more stable base.
--
You are receiving this mail because:
You are the assignee for the bug.