Skip to content
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

extended control of C/C++ validation #67

Open
barbieri opened this issue Apr 4, 2017 · 4 comments
Open

extended control of C/C++ validation #67

barbieri opened this issue Apr 4, 2017 · 4 comments

Comments

@barbieri
Copy link

barbieri commented Apr 4, 2017

Hi,

The current c_checker() and cpp_checker() uses a simple -I. -I.. which will get you some basic tests, but in real world we're often using things like pkg-config --cflags glib-2.0 and the likes to provide definitions and more include paths. Then a way to control INCLUDE_FLAGS would be required. I'm not sure how to best provide these extensions in a compatible way so we don't break sphinx, maybe using comments?

.. rstcheck-include-flags: -I.
.. rstcheck-pkg-config: glib-2.0
.. code-block: c
  regular code block here

Eventually allow these to be linked in addition to syntax check:

.. rstcheck-include-flags: -I.
.. rstcheck-pkg-config: glib-2.0
.. rstcheck-link: yes
.. code-block: c
  regular code block here

Likewise, sometimes in tutorial/documentation we split the code into multiple pieces that can't be validated at once. I could work-around that by using an external C/C++ file with include statements, however if we could add a argument to "append to previous block" it would be amazing, allowing things like rstcheck-mode with a choice of new, append and ignore:

.. code-block: c

  void on_event(void *ctx) {
   ...
  }

This provides a function to callback when event happens...

.. rstcheck-mode: append
.. code-block: c

  int main(void) {
   my_lib_init();
   my_lib_on_event_set(on_event, NULL);
   return 0;
  }
@myint
Copy link
Contributor

myint commented Apr 4, 2017

Very interesting! Allowing the user to configure the include paths definitely makes sense. And the approach you describe makes sense and basically matches what is done for the ignoring languages feature.

The appending code blocks would be cool. I think that is a decent solution.

@barbieri
Copy link
Author

barbieri commented Apr 4, 2017

great, this one is a bit trickier than the other issue I've opened in the sense it will need to accumulate from one statement to the other... the ignore of languages is a single step prior to start, it's not tied to the subsequent blocks.

Any preferences on how to tackle this? Maybe just a global stack where one pushes and then pops?

@myint
Copy link
Contributor

myint commented Apr 5, 2017

No preferences from my side. I agree that it doesn't seem easy at all.

@Cielquan
Copy link
Contributor

Does rstcheck/rstcheck#88 help here?

@Cielquan Cielquan transferred this issue from rstcheck/rstcheck Sep 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants