Open dzid26 opened 4 months ago
Thanks for this hint.
I fixed this in the current master.
Furthermore I improved the error message when the C-code is invalid and a ParseError
is generated (now the exact position in the C code and the error reason of the first error are displayed).
Ok, I get more meaningful errors now. Thank you.
The example from docs works now. Although it would be nice to print some messages:
print("Testing: ts.increment(10) == 11")
print("Testing: int_var == 11")
print("Testing: ts.increment_via_extfunc(10) == 11")
print("done")
The example from README doesn't work. I just copy pasted the code to dummy.c and test_dummy.py. When I run, i get:
c:/Users/dzidm/headlock/test_dummy.py
Traceback (most recent call last):
File "C:\Users\dzidm\headlock\.venv\Lib\site-packages\headlock\testsetup.py", line 145, in __set_builddesc__
parser.read(c_src)
File "C:\Users\dzidm\headlock\.venv\Lib\site-packages\headlock\c_parser.py", line 470, in read
raise ParseError([
headlock.c_parser.ParseError: 1 compile errors ('underlying_module.h' file not found in C:\Users\dzidm\headlock\dummy.c:1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "c:\Users\dzidm\headlock\test_dummy.py", line 3, in <module>
@CModule('dummy.c', MACRO_1=1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\dzidm\headlock\.venv\Lib\site-packages\headlock\testsetup.py", line 334, in __call__
ts.__set_builddesc__(builddesc)
File "C:\Users\dzidm\headlock\.venv\Lib\site-packages\headlock\testsetup.py", line 148, in __set_builddesc__
raise exc
headlock.testsetup.CompileError: building C:\Users\dzidm\headlock\dummy.c failed: 1 compile errors
PS C:\Users\dzidm\headlock>
I expect examples to just work.
If headlock could test things without external (underlying) headers , it would be quite amazing.
I could add the underlying header to the README.
But why do you want to omit it? In practise you have an underlying C module with a header file. Actually the header file is used for retrieving types to automaticially mock the underlying module...
I don't know the exact purpose of a new project, I am relying on accuracy of the examples. I would add the header to the example.
I thought that maybe missing types of a mocked function could be magically defined in python (or something).
I didn't give a proper try to headlock yet.
But I think there is gap in test suites in that it is hard to test one simple static function from C - which is all I need for a non-critical project. Once I start loading the all the includes I run into compiler extensions issues and what not.
Maybe parsing out the function as text from c file and feeding it to cffi and defining cdef is best for me.
If you want to give headlock a try please let me know your compiler setup and I will try to solve the "compiler extension issues".
I have some gotchas after giving it a try:
-D__interrupt(x)
can be pass to @CModule
using a dictionary: e.g. @CModule(sources, fake_include, include_dirs=include_dirs, predef_macros={"STM8S105": None, "__CDT_PARSER__": None, "__interrupt(x)": ""})
include_dirs = [os.path.abspath(path) for path in ["src/", "src/STM8S_StdPeriph_Lib/inc/", "C:/Program Files/SDCC/include"]]
-Werror
to silence warnings https://github.com/mrh1997/headlock/blob/4305e82221b970b9cb1296c98ac658656ba1bde9/headlock/buildsys_drvs/gcc.py#L117 After that I got stuck at compilation error:
.....test_with_headlock\TSSample\__headlock_bridge__.c:100:63: error: invalid use of undefined type 'enum FLASH_ProgramTime_TypeDef'
and similar. But the enum type is defined in headlock_bridge.c.
[headlock_bridge.c.txt](https://github.com/user-attachments/files/16113184/__headlock_bridge__.txt)
errors.txt
Unfortunately enum
(and float
) support is not implemented yet.
https://headlock.readthedocs.io/en/latest/getting-started.html#usage :
https://github.com/mrh1997/headlock?tab=readme-ov-file#sample