Servers by jDrones

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?

Servers by jDrones