[Ovmsdev] yacc/lex on component/dbc

Mark Webb-Johnson mark at webb-johnson.net
Sun Nov 25 20:49:56 HKT 2018


Craig,

The component.mk controls the compilation. It does:

yacc -o $(COMPONENT_PATH)/yacclex/dbc_parser.cpp -d $(COMPONENT_PATH)/src/dbc_parser.y

Expectation here is that the ‘-o’ produces dbc_parser.cpp and dbs_parser.hpp

lex -o $(COMPONENT_PATH)/yacclex/dbc_tokeniser.c $(COMPONENT_PATH)/src/dbc_tokeniser.l

This #include the dbc_parser.hpp and produced dbc_tokeniser.c

Then dbc_tokeniser.c and dbc_parser.cpp are compiled as normal

We use ‘yacclex’ as a temporary path, to keep these auto-generated code files separate.

The behaviour of bison is that ‘-o’ outputs both .hpp and .cpp files (from the ‘-o’ directive). If think byacc may behave differently. We need both the header and code files, and they need to be named .hpp and .cpp as they need to produce c++ code. The dbc_tokeniser is in C, as Lex only really supports C and we can “extern C” the stuff we need when we access it (there is not much).

Can you try running those commands manually, and see what comes out? Or try bison?

Regards, Mark

> On 25 Nov 2018, at 5:33 AM, Craig Leres <leres at xse.com> wrote:
> 
> On 11/22/18 8:38 PM, Mark Webb-Johnson wrote:
>> Could you guys check, and let me know if you see any issues? In particular, on windows. If no issues, I’ll proceed and finish up the grammar and implementation.
> 
> I'm unable to compile this under FreeBSD.
> 
> I think the first problem is really a FreeBSD bug. When !defined(__FreeBSD__) the generated code unconditionally defines __dead2 in flex.skl just before including stdio.h which includes sys/cdefs.h. But the toolchain version of sys/cdefs.h also defines __dead2. Here's the problem report I filed:
> 
>    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233481
> 
> After solving that my build fails with:
> 
>    CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_tokeniser.o
> /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_tokeniser.l:38:26: fatal error: dbc_parser.hpp: No such file or directory
>    compilation terminated.
>    gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:286: yacclex/dbc_tokeniser.o] Error 1
> 
> I suspect the makefile is assuming flex/lex will generate dbc_parser.hpp; mine generates dbc_parser.cpp. If i put in a symlink for dbc_parser.hppI can get incrementally further:
> 
>    CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_tokeniser.o
>    In file included from /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_tokeniser.l:38:0:
> /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_parser.y:43:18: fatal error: string: No such file or directory
>    compilation terminated.
>    gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:286: yacclex/dbc_tokeniser.o] Error 1
>    gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:468: component-dbc-build] Error 2
> 
> That looks c++ code in dbc_parser.y that's being compiled with the C compiler?
> 
>    #include <string>
> 
> If I change it to string.h then I have problems with dbc.h:
> 
>    #include <string>
>    #include <map>
>    #include <list>
> 
> And in this case it looks like dbc.h is included by both c++ and C sources.
> 
> 		Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181125/ebed4c6b/attachment.html>


More information about the OvmsDev mailing list