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)

defect

Tracking

(Not tracked)

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
Blocks: oxidation
Blocks: 1340637
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?
(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.
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.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.