-
Notifications
You must be signed in to change notification settings - Fork 9
Support for PCRE2 #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The current PCRE-bindings satisfy my needs. If you need further functionality, feel free to submit pull requests, but please make sure that the API stays backward compatible and that the library can be compiled with older PCRE versions. |
Do you get any special software development concerns from introducing the usage of the prefix “pcre2” into the current source files? |
Yes, not everybody may have pcre2, there may be portability issues, etc. It's probably going to take a significant effort to support the new API. Not sure it's worth the effort. |
|
No, by this I meant that people use pcre on a large variety of platforms, some of which may not even have pcre2. If you want to make sure that they can still use the older pcre installation, you would have to add potentially non-trivial autoconfiguration code. You might also consider writing completely separate OCaml bindings for Pcre2 and leverage already existing OCaml code from the current bindings for that purpose. It might make some problems (e.g. backward compatibility) easier to solve. |
|
It would probably be best to just start a fresh tree and copy as much as possible from the previous version. The amount of maintenance required will typically depend on the quality of the bindings (bugs) and how likely there will be portability issues. |
I suggest to switch to the PCRE2 programming interface at a specific version of your OCaml library. |
The latest release or even head of the master branch. This should make it easiest to adopt future changes. |
Will other branch names be a bit safer for corresponding patch merges? |
There are currently no other branches. Feature branches are typically merged and eventually deleted. |
I suggest to introduce a clearer separation between development branches. |
How do you think about to use any software improvements which are mentioned in the PCRE change log? |
If I had a personal need for a feature, I would implement it, but the current PCRE API satisfies my needs. Feel free to contribute any patches that support unimplemented features. |
Do your needs (or requirements by other contributors) evolve in a way which can include the use of a software like “PCRE 10.32”? |
My needs in that respect haven't changed. |
Thanks for another feedback.
|
As long as older software solves your problem, there is not much of an incentive to switch. If it isn't broken, don't fix it. If you have other needs, do it yourself or find other people with similar needs to help you. |
The PCRE software was improved several times in the meantime.
|
I'm not aware of any technical issues with the current PCRE library. It has all the features I need and works flawlessly and efficiently. Yes, as a matter of fact it is difficult to find people with similar software development interests. I have certainly never succeeded in getting my problems fixed by just waiting for other people to do that. |
|
If I needed an extension, I'd write it myself. There is no other incentive. |
I am just looking again for possibilities and system preparations for corresponding software adjustments. |
How are the chances to support the current version (≧ “10.22”) of this programming interface for Perl-compatible regular expressions?
The text was updated successfully, but these errors were encountered: