This PR implements generation of scintilla_object_* wrappers for each exported sci_* function. The intention is that scintilla_object_* can be used as true object methods for GeanyScintilla.
e.g. python: text = sci.get_text() instead of text = Geany.sci_get_text(sci) You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/935
-- Commit Summary --
* gen-api-gtkdoc.py: Add switch to write out scintilla_object methods * gen-sci-methods.py: add script to generate scintilla_object wrappers * Generate scimethods.c and link into libgeany * doc: Generate geany-scintilla-gtkdoc.h along geany-gtkdoc.h
-- File Changes --
M doc/Makefile.am (9) M scripts/gen-api-gtkdoc.py (23) A scripts/gen-sci-methods.py (144) M src/Makefile.am (21) M src/sciwrappers.c (22)
-- Patch Links --
https://github.com/geany/geany/pull/935.patch https://github.com/geany/geany/pull/935.diff
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935
See https://github.com/kugel-/peasy/blob/master/plugins/modeline.py#L130 for an example
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192764139
Travis is on Ubuntu 12.04, while pycparser is available in 14.04 and later. How we can resolve this?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192846234
If pycparser is not an option let me suggest to simply check the generated scimethods.c in for a few releases.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192847906
I don't like the idea of generating a source file to create alias symbols, just because the GIR generator tool can't be properly told to put those as methods of the object.
Can't you, instead of actually adding the symbols, trick the tool to understand what you want? Basically, rename the symbols it parses, and then fix them back in the output so they refer the actual name.
Maybe something roughly around those lines: ```shell TEMP_HEADER=geany-gtkdoc-sciobjected.h
sed 's/sci_/scintilla_object_/' geany-gtkdoc.h > $TEMP_HEADER g-ir-scanner ... $TEMP_HEADER sed 's/cname="scintilla_object_/cname="sci_/' -i Geany-1.0.gir ```
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192912469
If pycparser as a build dependency is not an option currently let me suggest to simply check the generated scimethods.c in for a few releases.
Do you really need another tool to parse the C code? Isn't the Doxygen stuff enough, as it's already used to generate some C header?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192912679
Am 06.03.2016 um 16:14 schrieb Colomban Wendling:
I don't like the idea of generating a source file to create alias symbols, just because the GIR generator tool can't be properly told to put those as methods of the object.
Can't you, instead of actually adding the symbols, trick the tool to understand what you want? Basically, rename the symbols it parses, and then fix them back in the output so they refer the actual name.
Maybe something roughly around those lines:
TEMP_HEADER=geany-gtkdoc-sciobjected.h
sed's/sci_/scintilla_object_/' geany-gtkdoc.h> $TEMP_HEADER g-ir-scanner ...$TEMP_HEADER sed's/cname="scintilla_object_/cname="sci_/' -i Geany-1.0.gir
I'd like to treat the .gir like a black box as far as possible because the format is not documented or stable, subject to change at any time. I don't consider the extra symbols to be that much of a problem to start processing the .gir.
I also don't want to lose access to the actual sci_* functions.
Do you really need another tool to parse the C code? Isn't the
Doxygen stuff enough, as it's already used to generate some C header?
Might be doable with the doxygen too. The problem with a doxygen-based solution is that the doxygen output is generated after lingeany is built, basically too late to add symbols to it.
Also, pycparser was quicker for me since the release is so soon.
If we can agree on shipping the symbols then I'd suggest to actually ship the .c file and deal with how to generate after the release (I'm not sure I'll manage to bring a doxygen-based solution in time).
Best regards.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192914969
I'd like to treat the .gir like a black box as far as possible because
the format is not documented or stable, subject to change at any time. I don't consider the extra symbols to be that much of a problem to start processing the .gir.
I don't consider the format possible instability (which is rather theoretical as there are more than one tool that deal with it, so it's unlikely to change enough to break much things) not really a reason enough to drop in what I see as useless symbols. And that we should maintain either manually or trusting a generation script that will parse C to generate actual code in the library.
And as a proof of concept, although it's indeed somewhat hacky, I successfully generated what looks like a proper GIR simply replacing a few symbols before and after: https://gist.github.com/b4n/75806eaaa87f3b0990a7 Sure it's not as neat as would be having everything recognized out of the box by g-ir-scanner, but it seems better to me than adding more complex stuff to sneak in extra symbols just to make it happy.
Might be doable with the doxygen too. The problem with a doxygen-based
solution is that the doxygen output is generated after lingeany is built, basically too late to add symbols to it.
Fair point.
If we can agree on shipping the symbols then I'd suggest to actually
ship the .c file and deal with how to generate after the release (I'm not sure I'll manage to bring a doxygen-based solution in time).
POssibly, but I really would rather avoid that.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#issuecomment-192998243
Closed #935.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/935#event-582490677
github-comments@lists.geany.org