[Ovmsdev] yacc/lex on component/dbc

Mark Webb-Johnson mark at webb-johnson.net
Wed Dec 5 13:24:11 HKT 2018


Craig,

I had a look at this, and it doesn’t seem at all easy to resolve.

The espressif build system uses component.mk to control the build. In our dbc component, the .hpp and .cpp files in yacclex are dynamically built. Then there is a COMPONENT_SRCDIRS variable that controls which directories the build system will look into for files to compile.

I think that what is happening, with concurrent build jobs, is that the component library object is being built at the same time as the yacclex dynamic builds. When the component library build starts, it generates a list of files (.c, .cpp, etc) to compile - but if that is done before the yacclex files are dynamically built, the issue you describe happens.

I can see a way to split this into two components (perhaps in the same dbc directory) - the first containing the dynamic content, and the second containing the main dbc component. Then we can set a component dependency for the main component depending on the dynamic content component.

But, I can’t see any obvious way of setting an explicit dependency for this dynamic content. Any ‘make’ gurus out there?

As an alternative, very hacky, solution, I added this to component.mk:

.NOTPARALLEL:

:-)

Regards, Mark.

> On 1 Dec 2018, at 10:28 AM, Craig Leres <leres at xse.com> wrote:
> 
> I tried building on FreeBSD and parallel make is broken:
> 
>    % make -j8
> [...]
>    gmake[1]: *** No rule to make target 'yacclex/dbc_parser.o', needed by 'libdbc.a'.  Stop.
>    gmake[1]: *** Waiting for unfinished jobs....
>    YACC dbc_parser.y
> 
> If I start a non-parallel build after the above failure it works ok (and probably first builds the things that are missing make dependencies). See appended.
> 
> I flashed it and it runs but this is with my dev module that does not have a modem and is literally on the bench.
> 
> I'm not very experienced with gmake but am willing to try and help if you can't figure out how fix the missing dependency (which might well be in the esp-idf tree).
> 
> 		Craig
> 
> ice 96 % gmake
> LEX dbc_tokeniser.l
> CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/src/dbc.o
> CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_tokeniser.o
> CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_parser.o
> AR /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/libdbc.a
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/esp_http_client.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_utils.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_auth.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport_tcp.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport_ssl.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_header.o
> AR /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/libesp_http_client.a
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/emac_main.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/emac_dev.o
> CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/eth_phy/phy_tlk110.o
> [...]

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


More information about the OvmsDev mailing list