AP_Scripting: correct compilation when !AP_SCRIPTING_BINDING_VEHICLE_ENABLED

[peterbarker]

Fixes:

../../libraries/AP_Scripting/lua_bindings.cpp: In function 'int lua_AP_Vehicle_set_target_velocity_NED(lua_State*)': ../../libraries/AP_Scripting/lua_bindings.cpp:1240:23: error: 'check_AP_Vehicle' was not declared in this scope; did you mean 'check_AC_Fence'?
 1240 |     AP_Vehicle * ud = check_AP_Vehicle(L);
      |                       ^~~~~~~~~~~~~~~~
      |                       check_AC_Fence
compilation terminated due to -Wfatal-errors.

Tested with:

pbarker@crun:~/rc/ardupilot(master)$ ./Tools/autotest/test_build_options.py --define-match-glob=AP_SCRIPTING_BINDING_VEHICLE_ENABLED --build-target plane

[andyp1per]

This seems messed up to me. The config element is not dependent on AP_VEHICLE_ENABLED which I think it should be. Also the implementations in Copter (for example) are conditionally compiled via #if AP_SCRIPTING_ENABLED which is different again

[peterbarker]

This seems messed up to me. The config element is not dependent on AP_VEHICLE_ENABLED which I think it should be. Also the implementations in Copter (for example) are conditionally compiled via #if AP_SCRIPTING_ENABLED which is different again

Yes, it definitely should be dependent on AP_VEHICLE_ENABLED. Not sure why it is not. Only Periph would be affected and it turns it off explicitly.

Copter could (and should probably) use the narrower define.

[peterbarker]

I've pushed up a patch which adds the dependency on AP_VEHICLE_ENABLED (and AP_SCRIPTING_ENABLED....).

I've looked at Copter. Using the tighter define might be good in that it adds information about the method - the fact that you probably don't want to call it in general ArduCopter code, rather just from scripting). I don't think it's worth the hassle of including a patch for that in this PR, 'though.