Tests fail: NameError: name 'sys' is not defined

[yurivict]

===>  Testing for nanopb-0.4.6.4
===>   nanopb-0.4.6.4 depends on executable: scons - found
===>   nanopb-0.4.6.4 depends on file: /usr/local/bin/python3.9 - found
scons: Reading SConscript files ...
NameError: name 'sys' is not defined:
  File "/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4/tests/SConstruct", line 51:
    env.Tool("nanopb")
  File "/usr/local/lib/python3.9/site-packages/SCons/Environment.py", line 1879:
    tool(self)
  File "/usr/local/lib/python3.9/site-packages/SCons/Tool/__init__.py", line 273:
    self.generate(env, *args, **kw)
  File "/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4/tests/site_scons/site_tools/nanopb.py", line 192:
    env['PYTHON'] = _detect_python(env)
  File "/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4/tests/site_scons/site_tools/nanopb.py", line 74:
    return env['ESCAPE'](sys.executable)
*** Error code 2

Version: 0.4.6.4
scons-4.3.0
FreeBSD 13.1

[PetteriAimonen]

I added the missing import now.

That code path gets invoked only when there is no executable called python3 in path.

As a workaround, you can define environment variable PYTHON=/usr/local/bin/python3.9

[yurivict]

Defining PYTHON=/usr/local/bin/python3.9 didn't help.

[yurivict]

But with the latest commit tests work.

[yurivict]

Now tests fail in the middle:

[ OK ]   All patterns found in build/generator_relative_paths/test.pb.h
os.chdir('build/infinity_nan')
"/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4-3-gf84ad7f/generator/protoc" -I. -I"../.." -I"/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4-3-gf84ad7f/generator/proto" -I"/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4-3-gf84ad7f/generator" --nanopb_out=--source-extension=.c,--header-extension=.h:. "floats.proto"
os.chdir('/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4-3-gf84ad7f/tests')
cc -o build/infinity_nan/floats.pb.o -c -I/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4-3-gf84ad7f -Ibuild/common build/infinity_nan/floats.pb.c
cc -o build/infinity_nan/infinity_nan_test.o -c -I/disk-samsung/freebsd-ports/devel/nanopb/work/nanopb-0.4.6.4-3-gf84ad7f -Ibuild/common build/infinity_nan/infinity_nan_test.c
cc -o build/infinity_nan/infinity_nan_test build/infinity_nan/infinity_nan_test.o build/infinity_nan/floats.pb.o build/common/pb_decode.o build/common/pb_common.o
ld: error: undefined symbol: __signbitf
>>> referenced by infinity_nan_test.c
>>>               build/infinity_nan/infinity_nan_test.o:(check_floats)
>>> referenced by infinity_nan_test.c
>>>               build/infinity_nan/infinity_nan_test.o:(check_floats)

ld: error: undefined symbol: __signbit
>>> referenced by infinity_nan_test.c
>>>               build/infinity_nan/infinity_nan_test.o:(check_floats)
>>> referenced by infinity_nan_test.c
>>>               build/infinity_nan/infinity_nan_test.o:(check_floats)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [build/infinity_nan/infinity_nan_test] Error 1
scons: building terminated because of errors.

[PetteriAimonen]

Ah, about the PYTHON environment variable, looks like it doesn't really get passed from the system environment. It might make sense to change that.

About the link error, it probably wants libm linking for some reason. scons LINKLIBS=-lm might work, but I'm unsure what is the correct fix here that would be portable also to platforms that don't have/need libm.

[yurivict]

scons LINKLIBS=-lm succeeds.

[PetteriAimonen]

Ok, so TODO items (low priority in my opinion, but worth doing):

• Consider whether the variables used in tests/site_scons/site_tools/nanopb.py should be made passable from either system environment or from scons command line.
• See if there is a way to portably add libm to the default link command for tests that include math.h.

[PetteriAimonen]

The -lm link flag should now be automatically detected.

Making Python interpreter configurable using environment variable is not currently possible because the call goes through protoc. Setting up a python virtualenv should work though, as venv modifies the system $PATH.