Front page | perl.perl5.porters |
Postings from June 2011
Re: [PATCH] export store_cop_label
From: Reini Urban
June 21, 2011 06:12
Re: [PATCH] export store_cop_label
Message ID: BANLkTimLujfnBEWX00nJWt6uimctz9TZOw@mail.gmail.com
Attached is a slightly revised patch. make regen required.
Did not touch global.sym perms
The utf-8 codepoint is now actually utf-8.
Fully exported not just experimental.
This needs to go to blead, 5.14 and 5.12
2011/6/18 Reini Urban <email@example.com>:
> 2011/6/13 Jan Dubois <firstname.lastname@example.org>:
>> On Mon, 13 Jun 2011, Nicholas Clark wrote:
>>> On Mon, Jun 13, 2011 at 01:13:38PM -0700, Jan Dubois wrote:
>>> > The issue (as far as I am concerned) is that none of the porters has "blessed"
>>> > the now documented API as something they want to support going forward. Instead
>>> > I read that Nicholas has a plan to implement a proper API for this kind of
>>> > functionality. So I think we are all waiting for this to happen.
>>> What I thought I'd written was that
>>> a: I got the impression that there were doubts over whether this was a sane
>>> API (to support indefinitely)(I know that fetch_cop_label changed about a
>>> year ago - it wasn't "right" the first time)
>>> b: If no-one else gets there first, I was intending to look at it
>> Sorry to put words into your mouth (and thereby kind of volunteering
>> you, when you were still hoping for someone else to get to it first). I
>> guess I need to increase the font size on my browser/email/IRC client.
>>> > Exporting the current symbol in maintenance branches is a completely separate
>>> > issue. Personally I don't see a big issue with it, as it can't possibly
>>> > break other code; it simply exports an additional symbols that is already
>>> > exported on most platforms anyways, although technically this may not be covered
>>> > by our maintenance policy. The biggest issues is that it will create
>>> > the expectation that the symbol will continue to be exported in newer releases.
>>> > This should cease to be a problem once the new API materializes.
>>> c: because the current maint policy that Jesse is working to is strict about
>>> what can go into a maint branch, and because this change is *not* something
>>> that the policy permits, then (on the assumption that the policy isn't going
>>> to change) there wasn't an urgency for me to look at it "yesterday", as not
>>> looking at this month it does not cause a (further) delay.
>>> By the current maint policy, this would be for 5.16.0, not for 5.14.anything.
> No, I consider it as a regression to be fixed for 5.12 and 5.14.
> COP labels could be written until then,
> they where written via the public API in the headers,
> and they are broken since the public macro was rewritten as private function.
>> Absolutely. I was trying to say that when we have a proper solution for 5.16,
>> then there is no longer an expectation that the old symbol would be exported
>> as well. Therefore it would do little harm in exporting it as-is in older maint
>> versions. I'm just saying it is not *obvious* if this would be allowable
>> under the current maint policy; it would essentially be a judgement call by Jesse.
> Better an unsane API as a removed API at all.
> There was only the vague objection from Nick that it is a new API, he
> need to think it over.
> I saw no other objections, I see no technical arguments why it "could"
> be a bad API and I see
> no risks exposing it as there are only two experimental modules using
> it, and I am the
> maintainer of both. So I can adjust to next changes fast.
> Two main releases thinking about it and blocking it hereby is
> definitely too long.
> The compiler can not be used for windows users for 5.12 and 5.14.
> The cygwin package has store_cop_label exported (by emulating the linux policy
> -Wl,--export-all-symbols), and I recommend that ActiveState and
> strawberry flip this
> one-char flag also in their subsequent updates for 5.12 an 5.14.