Open
Bug 1341041
Opened 7 years ago
Updated 2 years ago
KeyError: u'RUST_TARGET' when building RUST_PROGRAM with artifact builds enabled
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
NEW
People
(Reporter: ato, Unassigned)
References
Details
Steps to reproduce: % echo 'ac_add_options --enable-artifact-builds' >mozconfig % cargo new --bin hello % cat <<EOT >>hello/Cargo.toml [[bin]] name = "hello" EOT % echo 'RUST_PROGRAMS = ["hello"]' >hello/moz.build % echo 'DIRS += ["hello"]' >>moz.build % ./mach build Actual output: % ./mach build 0:00.30 /usr/bin/make -f client.mk -sNone 0:01.12 Adding client.mk options from /home/ato/src/gecko/mozconfig:None 0:01.13 MOZ_OBJDIR=/home/ato/src/gecko/obj-x86_64-pc-linux-gnuNone 0:01.13 OBJDIR=/home/ato/src/gecko/obj-x86_64-pc-linux-gnuNone 0:01.13 FOUND_MOZCONFIG=/home/ato/src/gecko/mozconfigNone 0:01.15 cat: backend.FasterMake+RecursiveMakeBackend.in: No such file or directoryNone 0:01.16 Build configuration changed. Regenerating backend.None 0:01.30 Reticulating splines...None 0:05.62 Traceback (most recent call last):None 0:05.62 File "config.status", line 904, in <module>None 0:05.62 config_status(**args)None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/config_status.py", line 150, in config_statusNone 0:05.62 the_backend.consume(definitions)None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/backend/base.py", line 126, in consumeNone 0:05.62 for obj in objs:None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 183, in emitNone 0:05.62 objs = list(emitfn(out))None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 996, in emit_from_contextNone 0:05.62 for obj in self._handle_linkables(context, passthru, generated_files):None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 533, in _handle_linkablesNone 0:05.62 self._binaries[program] = cls(context, program, cargo_file)None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/frontend/data.py", line 449, in __init__None 0:05.62 cargo_dir = cargo_target_directory(context, self.TARGET_SUBST_VAR)None 0:05.62 File "/home/ato/src/gecko/python/mozbuild/mozbuild/frontend/data.py", line 430, in cargo_target_directoryNone 0:05.62 return mozpath.join(context.config.substs[target_var], rust_build_kind)None 0:05.62 KeyError: u'RUST_TARGET'None 0:05.79 /home/ato/src/gecko/build/rebuild-backend.mk:24: recipe for target 'backend.FasterMake+RecursiveMakeBackend' failedNone 0:05.79 make[2]: *** [backend.FasterMake+RecursiveMakeBackend] Error 1None 0:05.79 /home/ato/src/gecko/client.mk:419: recipe for target 'realbuild' failedNone 0:05.79 make[1]: *** [realbuild] Error 2None 0:05.79 client.mk:170: recipe for target 'build' failedNone 0:05.79 make: *** [build] Error 2None 0:05.82 6246 compiler warnings present.None Expected output: 0:15.17 the lock file needs to be updated but --locked was passed to prevent thisNone 0:15.17 /home/ato/src/gecko/config/rules.mk:982: recipe for target 'force-cargo-program-build' failedNone 0:15.17 make[5]: *** [force-cargo-program-build] Error 101None
Comment 1•7 years ago
|
||
This is certainly a terrible error message, but it's probably because we decided 'artifact build' meant 'no compilers' not just 'no C++ compiler'. Is geckodriver a good argument for changing that?
Comment 2•7 years ago
|
||
(In reply to Ralph Giles (:rillian) | needinfo me from comment #1) > This is certainly a terrible error message, but it's probably because we > decided 'artifact build' meant 'no compilers' not just 'no C++ compiler'. Is > geckodriver a good argument for changing that? I tend to think it is not, because geckodriver is (IIUC) equivalent to the other compiled programs specific to testing, including xpcshell and the cert utilities. We should be able to fetch it from the *tests*zip packages, just like the others; and I wouldn't expect to be able to _develop_ it using an artifact tree.
Comment 3•7 years ago
|
||
Guarding this directory's traversal with `if CONFIG['COMPILE_ENVIRONMENT']` will probably be a reasonable work around for now -- I don't see a clean way to avoid this error as is without adding extra conditions to the emitter. Once we're building/uploading the program we should make sure it's being extracted from the resulting test archives correctly so we can run these tests against artifact builds, as Nick suggests.
Updated•6 years ago
|
Product: Core → Firefox Build System
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•