After todays Rebase, build (sitl or board) brings me an error about AP_Scripting/lua_generated_bindings

[3/4] Creating build/sitl/ap_version.h
[4/4] Processing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.h: libraries/AP_Scripting/generator/description/bindings.desc build/sitl/gen-bindings -> build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp build/sitl/libraries/AP_Scripting/lua_generated_bindings.h
Error (line 2): Expected a keyword, got:

Waf: Leaving directory `/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitlā€™
Build failed
-> task in ā€˜/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.hā€™ failed (exit status 3):
{task 123145264233360: /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.h bindings.desc,gen-bindings -> lua_generated_bindings.cpp,lua_generated_bindings.h}
(run with -v to display more information)
ā€œc:/cygwin64/bin/python2.7 waf roverā€ terminated with exit code 1. Build might be incomplete.

18:42:55 Build Finished. 0 errors, 0 warnings. (took 5s.891ms)

How can I fix that?

I guess you have not been adding lua bindings?

./waf distclean is always a good thing to try first

You are right, I didnā€™t add any lua bindings.
A ./waf distclean was my first doing, 'cause I struggled on that two months ago.

Maybe that will help:
In the directory ā€œbuild/sitl/libraries/AP_Scriptingā€ there is no file at all, just an empty subdir ā€œluaā€ with an empty subdir ā€œsrcā€.

So the error is still the same:
(Btw. how can I insert a codefield with sliders?)

11:49:31 **** Build of configuration Default for project MissionRelative ****
ā€œc:\cygwin64\bin\python2.7ā€ waf rover
Waf: Entering directory /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl' [1/4] Compiling libraries/AP_Scripting/generator/src/main.c [2/4] Processing modules/mavlink/message_definitions/v1.0/ardupilotmega.xml [3/4] Creating build/sitl/ap_version.h [4/4] Processing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.h: libraries/AP_Scripting/generator/description/bindings.desc build/sitl/gen-bindings -> build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp build/sitl/libraries/AP_Scripting/lua_generated_bindings.h Error (line 2): Expected a keyword, got: Validation skipped for /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/ardupilotmega.xml. Parsing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/ardupilotmega.xml MAV_CMD MAV_CMD_DO_GRIPPER MAV_CMD_DO_AUTOTUNE_ENABLE MAV_CMD_DO_SET_RESUME_REPEAT_DIST MAV_CMD_NAV_ALTITUDE_WAIT MAV_CMD_POWER_OFF_INITIATED MAV_CMD_SOLO_BTN_FLY_CLICK MAV_CMD_SOLO_BTN_FLY_HOLD MAV_CMD_SOLO_BTN_PAUSE_CLICK MAV_CMD_FIXED_MAG_CAL MAV_CMD_FIXED_MAG_CAL_FIELD MAV_CMD_FIXED_MAG_CAL_YAW MAV_CMD_DO_START_MAG_CAL MAV_CMD_DO_ACCEPT_MAG_CAL MAV_CMD_DO_CANCEL_MAG_CAL MAV_CMD_ACCELCAL_VEHICLE_POS MAV_CMD_DO_SEND_BANNER MAV_CMD_SET_FACTORY_TEST_MODE MAV_CMD_GIMBAL_RESET MAV_CMD_GIMBAL_AXIS_CALIBRATION_STATUS MAV_CMD_GIMBAL_REQUEST_AXIS_CALIBRATION MAV_CMD_GIMBAL_FULL_RESET MAV_CMD_DO_WINCH MAV_CMD_FLASH_BOOTLOADER MAV_CMD_BATTERY_RESET MAV_CMD_DEBUG_TRAP MAV_CMD_SCRIPTING MAV_CMD_GUIDED_CHANGE_SPEED MAV_CMD_GUIDED_CHANGE_ALTITUDE MAV_CMD_GUIDED_CHANGE_HEADING Note: message DATA64 is longer than 64 bytes long (74 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message DATA96 is longer than 64 bytes long (106 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message REMOTE_LOG_DATA_BLOCK is longer than 64 bytes long (214 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message EFI_STATUS is longer than 64 bytes long (73 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message DEVICE_OP_READ_REPLY is longer than 64 bytes long (143 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message DEVICE_OP_WRITE is longer than 64 bytes long (187 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Validation skipped for /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/common.xml. Parsing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/common.xml MAV_CMD MAV_CMD_NAV_WAYPOINT MAV_CMD_NAV_LOITER_UNLIM MAV_CMD_NAV_LOITER_TURNS MAV_CMD_NAV_LOITER_TIME MAV_CMD_NAV_RETURN_TO_LAUNCH MAV_CMD_NAV_LAND MAV_CMD_NAV_TAKEOFF MAV_CMD_NAV_LAND_LOCAL MAV_CMD_NAV_TAKEOFF_LOCAL MAV_CMD_NAV_FOLLOW MAV_CMD_NAV_CONTINUE_AND_CHANGE_ALT MAV_CMD_NAV_LOITER_TO_ALT MAV_CMD_DO_FOLLOW MAV_CMD_DO_FOLLOW_REPOSITION MAV_CMD_NAV_ROI MAV_CMD_NAV_PATHPLANNING MAV_CMD_NAV_SPLINE_WAYPOINT MAV_CMD_NAV_VTOL_TAKEOFF MAV_CMD_NAV_VTOL_LAND MAV_CMD_NAV_GUIDED_ENABLE MAV_CMD_NAV_DELAY MAV_CMD_NAV_PAYLOAD_PLACE MAV_CMD_NAV_LAST MAV_CMD_CONDITION_DELAY MAV_CMD_CONDITION_CHANGE_ALT MAV_CMD_CONDITION_DISTANCE MAV_CMD_CONDITION_YAW MAV_CMD_CONDITION_LAST MAV_CMD_DO_SET_MODE MAV_CMD_DO_JUMP MAV_CMD_DO_CHANGE_SPEED MAV_CMD_DO_SET_HOME MAV_CMD_DO_SET_PARAMETER MAV_CMD_DO_SET_RELAY MAV_CMD_DO_REPEAT_RELAY MAV_CMD_DO_SET_SERVO MAV_CMD_DO_REPEAT_SERVO MAV_CMD_DO_FLIGHTTERMINATION MAV_CMD_DO_CHANGE_ALTITUDE MAV_CMD_DO_LAND_START MAV_CMD_DO_RALLY_LAND MAV_CMD_DO_GO_AROUND MAV_CMD_DO_REPOSITION MAV_CMD_DO_PAUSE_CONTINUE MAV_CMD_DO_SET_REVERSE MAV_CMD_DO_SET_ROI_LOCATION MAV_CMD_DO_SET_ROI_WPNEXT_OFFSET MAV_CMD_DO_SET_ROI_NONE MAV_CMD_DO_SET_ROI_SYSID MAV_CMD_DO_CONTROL_VIDEO MAV_CMD_DO_SET_ROI MAV_CMD_DO_DIGICAM_CONFIGURE MAV_CMD_DO_DIGICAM_CONTROL MAV_CMD_DO_MOUNT_CONFIGURE MAV_CMD_DO_MOUNT_CONTROL MAV_CMD_DO_SET_CAM_TRIGG_DIST MAV_CMD_DO_FENCE_ENABLE MAV_CMD_DO_PARACHUTE MAV_CMD_DO_MOTOR_TEST MAV_CMD_DO_INVERTED_FLIGHT MAV_CMD_NAV_SET_YAW_SPEED MAV_CMD_DO_SET_CAM_TRIGG_INTERVAL MAV_CMD_DO_MOUNT_CONTROL_QUAT MAV_CMD_DO_GUIDED_MASTER MAV_CMD_DO_GUIDED_LIMITS MAV_CMD_DO_ENGINE_CONTROL MAV_CMD_DO_SET_MISSION_CURRENT MAV_CMD_DO_LAST MAV_CMD_PREFLIGHT_CALIBRATION MAV_CMD_PREFLIGHT_SET_SENSOR_OFFSETS MAV_CMD_PREFLIGHT_UAVCAN MAV_CMD_PREFLIGHT_STORAGE MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN MAV_CMD_OVERRIDE_GOTO MAV_CMD_MISSION_START MAV_CMD_COMPONENT_ARM_DISARM MAV_CMD_GET_HOME_POSITION MAV_CMD_START_RX_PAIR MAV_CMD_GET_MESSAGE_INTERVAL MAV_CMD_SET_MESSAGE_INTERVAL MAV_CMD_REQUEST_MESSAGE MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES MAV_CMD_REQUEST_CAMERA_INFORMATION MAV_CMD_REQUEST_CAMERA_SETTINGS MAV_CMD_REQUEST_STORAGE_INFORMATION MAV_CMD_STORAGE_FORMAT MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS MAV_CMD_REQUEST_FLIGHT_INFORMATION MAV_CMD_RESET_CAMERA_SETTINGS MAV_CMD_SET_CAMERA_MODE MAV_CMD_JUMP_TAG MAV_CMD_DO_JUMP_TAG MAV_CMD_IMAGE_START_CAPTURE MAV_CMD_IMAGE_STOP_CAPTURE MAV_CMD_DO_TRIGGER_CONTROL MAV_CMD_VIDEO_START_CAPTURE MAV_CMD_VIDEO_STOP_CAPTURE MAV_CMD_LOGGING_START MAV_CMD_LOGGING_STOP MAV_CMD_AIRFRAME_CONFIGURATION MAV_CMD_CONTROL_HIGH_LATENCY MAV_CMD_PANORAMA_CREATE MAV_CMD_DO_VTOL_TRANSITION MAV_CMD_ARM_AUTHORIZATION_REQUEST MAV_CMD_SET_GUIDED_SUBMODE_STANDARD MAV_CMD_SET_GUIDED_SUBMODE_CIRCLE MAV_CMD_NAV_FENCE_RETURN_POINT MAV_CMD_NAV_FENCE_POLYGON_VERTEX_INCLUSION MAV_CMD_NAV_FENCE_POLYGON_VERTEX_EXCLUSION MAV_CMD_NAV_FENCE_CIRCLE_INCLUSION MAV_CMD_NAV_FENCE_CIRCLE_EXCLUSION MAV_CMD_NAV_RALLY_POINT MAV_CMD_UAVCAN_GET_NODE_INFO MAV_CMD_PAYLOAD_PREPARE_DEPLOY MAV_CMD_PAYLOAD_CONTROL_DEPLOY MAV_CMD_WAYPOINT_USER_1 MAV_CMD_WAYPOINT_USER_2 MAV_CMD_WAYPOINT_USER_3 MAV_CMD_WAYPOINT_USER_4 MAV_CMD_WAYPOINT_USER_5 MAV_CMD_SPATIAL_USER_1 MAV_CMD_SPATIAL_USER_2 MAV_CMD_SPATIAL_USER_3 MAV_CMD_SPATIAL_USER_4 MAV_CMD_SPATIAL_USER_5 MAV_CMD_USER_1 MAV_CMD_USER_2 MAV_CMD_USER_3 MAV_CMD_USER_4 MAV_CMD_USER_5 MAV_CMD_ACK MAV_CMD_ACK_OK MAV_CMD_ACK_ERR_FAIL MAV_CMD_ACK_ERR_ACCESS_DENIED MAV_CMD_ACK_ERR_NOT_SUPPORTED MAV_CMD_ACK_ERR_COORDINATE_FRAME_NOT_SUPPORTED MAV_CMD_ACK_ERR_COORDINATES_OUT_OF_RANGE MAV_CMD_ACK_ERR_X_LAT_OUT_OF_RANGE MAV_CMD_ACK_ERR_Y_LON_OUT_OF_RANGE MAV_CMD_ACK_ERR_Z_ALT_OUT_OF_RANGE Note: message GPS_STATUS is longer than 64 bytes long (109 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message ATTITUDE_QUATERNION_COV is longer than 64 bytes long (80 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message GLOBAL_POSITION_INT_COV is longer than 64 bytes long (189 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message LOCAL_POSITION_NED_COV is longer than 64 bytes long (233 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message HIL_ACTUATOR_CONTROLS is longer than 64 bytes long (89 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message GLOBAL_VISION_POSITION_ESTIMATE is longer than 64 bytes long (125 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message VISION_POSITION_ESTIMATE is longer than 64 bytes long (125 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message VISION_SPEED_ESTIMATE is longer than 64 bytes long (65 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message VICON_POSITION_ESTIMATE is longer than 64 bytes long (124 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message HIGHRES_IMU is longer than 64 bytes long (71 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message HIL_SENSOR is longer than 64 bytes long (72 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message SIM_STATE is longer than 64 bytes long (92 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message FILE_TRANSFER_PROTOCOL is longer than 64 bytes long (262 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message HIL_STATE_QUATERNION is longer than 64 bytes long (72 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message LOG_DATA is longer than 64 bytes long (105 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message GPS_INJECT_DATA is longer than 64 bytes long (121 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message SERIAL_CONTROL is longer than 64 bytes long (87 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message ENCAPSULATED_DATA is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message ATT_POS_MOCAP is longer than 64 bytes long (128 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message RESOURCE_REQUEST is longer than 64 bytes long (251 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message FOLLOW_TARGET is longer than 64 bytes long (101 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message CONTROL_SYSTEM_STATE is longer than 64 bytes long (108 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message AUTOPILOT_VERSION is longer than 64 bytes long (86 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message LANDING_TARGET is longer than 64 bytes long (68 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message GPS_INPUT is longer than 64 bytes long (73 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message GPS_RTCM_DATA is longer than 64 bytes long (190 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message HOME_POSITION is longer than 64 bytes long (68 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message SET_HOME_POSITION is longer than 64 bytes long (69 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message V2_EXTENSION is longer than 64 bytes long (262 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message PLAY_TUNE is longer than 64 bytes long (240 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message CAMERA_INFORMATION is longer than 64 bytes long (243 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message CAMERA_IMAGE_CAPTURED is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message LOGGING_DATA is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message LOGGING_DATA_ACKED is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message WIFI_CONFIG_AP is longer than 64 bytes long (104 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message AIS_VESSEL is longer than 64 bytes long (66 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message UAVCAN_NODE_INFO is longer than 64 bytes long (124 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message OBSTACLE_DISTANCE is longer than 64 bytes long (175 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message ODOMETRY is longer than 64 bytes long (240 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message DEBUG_FLOAT_ARRAY is longer than 64 bytes long (260 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message STATUSTEXT_LONG is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message ACTUATOR_OUTPUT_STATUS is longer than 64 bytes long (148 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Note: message WHEEL_DISTANCE is longer than 64 bytes long (145 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit. Validation skipped for /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/uAvionix.xml. Parsing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/uAvionix.xml Validation skipped for /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/icarous.xml. Parsing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/modules/mavlink/message_definitions/v1.0/icarous.xml Merged enum MAV_CMD Found 226 MAVLink message types in 4 XML files Generating C implementation in directory /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/GCS_MAVLink/include/mavlink/v2.0/ardupilotmega Generating C implementation in directory /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/GCS_MAVLink/include/mavlink/v2.0/common Generating C implementation in directory /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/GCS_MAVLink/include/mavlink/v2.0/uAvionix Generating C implementation in directory /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/GCS_MAVLink/include/mavlink/v2.0/icarous Copying fixed headers for protocol 2.0 to /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/GCS_MAVLink/include/mavlink/v2.0 Waf: Leaving directory /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitlā€™
Build failed
ā†’ task in ā€˜/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.hā€™ failed (exit status 3):
{task 123145248651096: /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.h bindings.desc,gen-bindings ā†’ lua_generated_bindings.cpp,lua_generated_bindings.h}
(run with -v to display more information)
ā€œc:/cygwin64/bin/python2.7 waf roverā€ terminated with exit code 1. Build might be incomplete.
11:49:49 Build Finished. 0 errors, 0 warnings. (took 17s.736ms)

Is it necessary to do that make manually?

grafik

on ā€˜masterā€™ the ā€˜make runā€™ is no longer required, if u are making older brances like 4.0beta-whatever release, then yes its probably needed.

I rebased two days ago and sitting on top of c1403a2e2b (Tridge: HAL_ChibiOS: fixed default CubeOrange pin for 2nd current sensor).
I edited bindings.des (just changing a comment), hoping that will activate the generator.
But the bindings-generator will not startā€¦
Error.txt (1.6 KB)

The manual start as mentioned in the README.md is not working (it seems, that is an older info):
Willy@17-04-2014-MEDI /cygdrive/c/users/willy/documents/github/ardupilot/libraries/AP_Scripting/generator
$ make run
make: *** Keine Regel, um ā€žrunā€œ zu erstellen. Schluss.

Is there a current way to start the generator manually? (Iā€™m working on Win10 with Cygwin64)

Itā€™s so frustrating.
My code is finished and tested in SITL and the last steps, a final rebase and a test in real flight, should happen on that four free days at good weather - and now the scripting is knocking me out.
I canā€™t build because of an AP_Scripting that I canā€™t use anyway in my 1MB FCs :worried:

I think Iā€™ve got it.
I started a test:

I deleted the empty line 2 in bindings.desc.
Then I started a build and the error moved to the empty line 10.

So it seems that the generator doesnā€™t accept empty lines.

I made an additional test:
All empty lines removed from bindings.desc.
./waf distclean
build

New Error:
[4/4] Processing /cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp,/cygdrive/c/Users/Willy/Documents/GitHub/ardupilot/build/sitl/libraries/AP_Scripting/lua_generated_bindings.h: libraries/AP_Scripting/generator/description/bindings.desc build/sitl/gen-bindings -> build/sitl/libraries/AP_Scripting/lua_generated_bindings.cpp build/sitl/libraries/AP_Scripting/lua_generated_bindings.h
Error (line 12): Unknown attribute: 'Null

here the line 12 of my bindings.desc:
userdata Location method get_vector_from_origin_NEU boolean Vector3f 'Null

So as it seems the generator or the bindings.desc-syntax has a problem. Maybe in connection with running on Win10/Cygwin?

Update:
Next test - editing the bindings.desc till it doesnā€™t generate an error disregarding function and completeness (renamed .txt for upload) bindings.txt (13.3 KB)

Iā€™ve got a new error: Error.txt (915 Bytes)

So I had a look at the generated files:
lua_generated_bindings.cpp (95.8 KB)
lua_generated_bindings.h (1.7 KB)
ā€¦and that are not ok for sure.

So is it possible, that the C-compiler on Windows-systems that is compiling the generator main.c is the wrong one? Itā€™s just an idea, but my background for further investigations in that case is missing.
Is my thinking right?

On my system:
$ cc --version
cc (GCC) 9.3.0
is that correct?

Could an experienced developer adress this to a developer that could ckeck that, please.

Is there any Win10/Cygwin-developer at whom the generator works correctly?
Is there any Win10/Cygwin-developer that has the same problem?
It would be good to know if thatā€™s my problem or if itā€™s a general problem.
I feel a little ā€˜lost in spaceā€™ - so every comment would be welcome.

I just fired up my Cygwin install, it is all working as it should on master for me.

So it seems itā€™s a problem on my system.
To find out the rootcause or to come nearer it would help to have the ready-compiled lua-generator (gen-bindings?)
@iampete Could you send it to me, please?
So I could see if the compilation of the generator or if the interpretation of the bindings.desc-file by the generator produces the problem.

lua_generated_bindings.cpp (102.9 KB) lua_generated_bindings.h (1.6 KB)

1 Like

Thank you @iampete, that will help, too.
But I meant the generator itself (itā€™s \ardupilot\build\sitl\ gen-bindings.exe , a compilation of main.c). It is building that two lua_generated_bindings-files out of bindings.desc.

I suspect a problem at compiling that generator out of main.c on my system.
In the corresponding build-file \libraries\AP_Scripting\wscript wscript.txt (1.8 KB) (renamed .txt for upload) I could find a little hint:
ā€œ# we should have configure tests for finding the native compilerā€.
Iā€™m not a native-speaker, but I hope to understand correctly that comment in that way, that Itā€™s critical to use the wrong compiler - maybe thatā€™s so in my case?

I started a compiling by CL with option -v
compile.txt (5.5 KB)
For me that output is not really helpful, but eventually an insider will see whatā€™s the error.

It would be good if you would do the same and we could compare the two outputs.

I also send you my gen-bindings.exe (renamed .txt for upload) gen-bindings.txt (197.9 KB)
It would be great if you could copy that to your build/sitl/ directory and start a build - I expect that you will also get an error "Error (line 2): Expected a keyword, got: "

Thank you very much Pete - without help of an experienced developer I wouldnā€™t know how to proceed.

https://drive.google.com/file/d/19HSULzY2k0JkpBpQP3OLsgUiaVc-IFFq/view?usp=sharing

1 Like

Thank you again for your support Pete - Iā€™ve got it.

Your gen-bindings.exe produced the same error than that compiled on my system out of main.c.
So the only difference could be the bindings.desc.

So I downloaded the bindings.desc of current master and compared it with the bindings.desc of my last rebase - and there is the rootcause:
The erroneous one of the rebase has a Win-format with CRLF and the correct one has a Unix-format with just LF. So in editor, both are looking identical, but in HexEdit you can see the difference.

Now with the Unix-format-file the building is working without any error.

I would recommend to improve the main.c so the generator will ignore any CR/0D to make it all-purpose-safe.
Iā€™ve seen, that you are a contributor to scripting. So would you forward that to the corresponding developer or should I start an issue?