Build system should warn more clearly about invalid OBJDIR paths

REOPENED
Unassigned

Firefox
Build Config
REOPENED
a year ago
a year ago

Details

(Reporter)

Description

a year ago
MOZCONFIG:

mk_add_options MOZ_OBJDIR=/c/mozilla/opt-art/
ac_add_options --enable-artifact-builds
ac_add_options --disable-compile-environment

./mach build:

2:00.65   2110 total backend files; 0 created; 0 updated; 2110 unchanged; 0 deleted
2:00.65 Total wall time: 16.74s; CPU time: 16.74s; Efficiency: 100%; Untracked: 3.11s
2:00.75 mozmake.EXE[1]: *** No rule to make target '/c/mozilla/opt-art/config.status', needed by 'realbuild'.  Stop.
2:00.75 client.mk:170: recipe for target 'build' failed
2:00.75 mozmake.EXE: *** [build] Error 2
2:00.79 0 compiler warnings present.

Earlier, in case it's relevant:
1:37.28 checking NSPR selection... source-tree
1:37.42 checking if app-specific confvars.sh exists... c:/mozilla/mozilla-unified/browser/confvars.sh
1:38.70 c:/mozilla/mozilla-unified/old-configure: line 13988: test: : integer expression expected
1:39.31 configure: warning: No assembler or assembly support for libav-fft.  Using unoptimized C routines.

old-configure, around that line, for me:

elif test -n "$COMPILE_ENVIRONMENT" -a "$_YASM_MAJOR_VERSION" -lt "1" -o $$"_YASM_MAJOR_VERSION" -eq "1" -a "_YASM_MINOR_VERSION" -lt "1"$$ ; then
{ echo "configure: error: yasm 1.1 or greater is required to build libvpx on Win32, but you appear to have version $_YASM_MAJOR_VERSION.$_YASM_MINOR_VERSION.  Upgrade to the newest version (included in MozillaBuild 1.5.1 and newer) or configure with --disable-webm (which disables the WebM video format). See https://developer.mozilla.org/en/YASM for more details." 1>&2; echo "configure: error: yasm 1.1 or greater is required to build libvpx on Win32, but you appear to have version $_YASM_MAJOR_VERSION.$_YASM_MINOR_VERSION.  Upgrade to the newest version (included in MozillaBuild 1.5.1 and newer) or configure with --disable-webm (which disables the WebM video format). See https://developer.mozilla.org/en/YASM for more details." 1>&5; exit 1; }

with the line in question being the one starting: { echo

I don't really know what else to do here, but this is blocking me and several others in the Photon work week from getting any work done on our windows machines.

Comment 1

a year ago
Don't use an msys path in MOZ_OBJDIR. Replace /c/ with c:
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
(Reporter)

Comment 2

a year ago
(In reply to Mike Hommey [:glandium] from comment #1)
> Don't use an msys path in MOZ_OBJDIR. Replace /c/ with c:

OK. But to a layperson like me, the error message is far from a clear indicator this is the problem. I tried a lot of things, including downloading and installing all of visual studio, checking the yasm version (which is where that (apparently unrelated?) error message is from), etc. etc.

Can we make the build system fail earlier in this case, with a sensible error message like "didn't understand path to objdir X, use path in format Y instead" ? This is especially true because while your comment was very accurate, my first attempt to fix my mozconfig had me using:

MOZ_OBJDIR=C:\path\to\objdir

which *also* doesn't work, but at least fails a lot more quickly and obviously. It's not really obvious that the One True Acceptable Path Format here is "kind of like Windows paths, but not quite".
Severity: blocker → normal
Status: RESOLVED → REOPENED
Flags: needinfo?(mh+mozilla)
Resolution: INVALID → ---
Summary: Can't build artifact builds on Windows - No rule to make target '/c/mozilla/opt-art/config.status' → Build system should warn more clearly about invalid OBJDIR paths

Comment 3

a year ago
MOZ_OBJDIR is one of many things where someone might pass paths. We just can't check everything and emit sensible errors for all of them, I'm afraid. That MOZ_OBJDIR=/c/mozilla/obj-art/ works up to some point is actually only luck. It could have failed way earlier, but just happened not to have. That might break in the future. Or not.

That MOZ_OBJDIR=C:\path\to\objdir doesn't work is expected, considering mozconfig is a shell script and that doing that in a shell script is going to consider the backslashes as opening escape sequences, so you need two backslashes if you want to use backslashes. Thus the windows paths with forward slashes, which you say are "kind of like Windows paths, but not quite", but in fact, forward slashes are fully supported by Windows.
Flags: needinfo?(mh+mozilla)

Comment 4

a year ago
While we can't error check everything in mozconfigs, MOZ_OBJDIR is pretty ubiquitous and I think having a better error message for invalid paths is a good idea.

I would implement that at https://hg.mozilla.org/mozilla-central/file/96b36c5f527d/python/mozbuild/mozbuild/base.py#l206. This will likely require rolling a new exception type ("InvalidMozconfigError" or some such) and catching that exception at https://hg.mozilla.org/mozilla-central/file/96b36c5f527d/python/mozbuild/mozbuild/base.py#l646 so we error gracefully.

I think it makes sense to implement this a layer above evaluating the mozconfig because the error is a logical error, not an error with the mozconfig file itself.
You need to log in before you can comment on or make changes to this bug.