Closed Bug 707512 Opened 12 years ago Closed 12 years ago

Windows pymake builds using MOZ_OBJDIR set to an MSYS style path, fail with an unclear: "No rule to make target '/c/<objdir>/config.status' needed by ['<command-line>', '/c/<objdir>/config.status']"


(Firefox Build System :: General, defect)

Windows 7
Not set


(Not tracked)



(Reporter: emorley, Assigned: emorley)


(Keywords: dev-doc-complete)


(2 files, 1 obsolete file)

Attached file Build log
When building from topsrcdir (after rm -rf objdir & removing the generated configures from srcdir) using:
"python -OO build/pymake/ -s -f" 
...and specifying the objdir in my /mozconfig:
mk_add_options MOZ_OBJDIR=/c/mozilla/obj-inbound

I get the following error (in addition to that mentioned in bug 707511):
No rule to make target '/c/mozilla/obj-inbound/config.status' needed by ['<command-line>', '/c/mozilla/obj-inbound/config.status']
(Full log attached)

I like having my objdir one level up from the srcdir, so currently my workaround (and the way I've been building for months, since until now I didn't realise MOZ_OBJDIR was supposed to work in pymake builds) is of course to just build from the objdir, using: "python -OO ../inbound/build/pymake/ -s -f ../inbound/".

Either MOZ_OBJDIR is supposed to work under pymake and this is a bug (or else just another side effect of bug 707511), or else if it's known unavoidably broken, then maybe I can just clarify on the build options/pymake pages and save others the hassle of trying to figure out why things aren't working :-)

- Windows 7 x64 (but building 32 bit)
- MozillaBuild 1.6 final
- MSVC2010
- WinSDK 7.0A
- Inbound tip as of 2011-12-02
- PATH: "%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\TortoiseHg\;c:\Program Files\Java\jdk1.7.0_01\bin\"
- In my .profile:
export MOZCONFIG=/c/mozilla/.mozconfig
- .mozconfig:
mk_add_options MOZ_OBJDIR=/c/mozilla/obj-inbound
mk_add_options MOZ_MAKE_FLAGS="-j3"
ac_add_options --disable-optimize
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests
ac_add_options --disable-angle
Ok, turns out things start working if I use:
mk_add_options MOZ_OBJDIR=c:/mozilla/obj-inbound

...which is counter-intuitive given that MozillaBuild lists paths in the /c/mozilla/foo form.

If this behaviour is intentional, then I'll update instructing windows users to use the correct from + list the error on the troubleshooting page & ideally we can add some kind of error message that is more helpful than that in comment 0.
Yes, pymake uses windows paths not msys paths. Feel free to make the error message reasonable.
Seems obvious in retrospect (such is life!) :-)

Morphing bug to be about adding an explicit error message.
Summary: Win pymake build failure with srcdir builds that have MOZ_OBJDIR set in mozconfig: "No rule to make target '/c/mozilla/obj-inbound/config.status' needed by ['<command-line>', '/c/mozilla/obj-inbound/config.status']" → Windows pymake builds using MOZ_OBJDIR set to an MSYS style path, fail with an unclear: "No rule to make target '/c/<objdir>/config.status' needed by ['<command-line>', '/c/<objdir>/config.status']"
Attached patch Patch v1 (obsolete) — Splinter Review
Adds an explicit error message iff MINGW* && PYMAKE && first character of MOZ_OBJDIR is a "/".

The indentation style in is slightly varied, so wasn't sure what to match, so went with that ifndef block's existing style. Happy to change it to whatever you'd prefer.
Assignee: nobody → bmo
Attachment #579193 - Flags: review?(ted.mielczarek)
Comment on attachment 579193 [details] [diff] [review]
Patch v1

Review of attachment 579193 [details] [diff] [review]:

@@ +141,5 @@
>  ifndef MOZ_OBJDIR
> +else
> +# On Windows Pymake builds check MOZ_OBJDIR doesn't start with "/"
> +  ifneq (,$(filter MINGW%,$(shell uname -s)))

Maybe use CONFIG_GUESS here instead of having to shell out again?
Attachment #579193 - Flags: review?(ted.mielczarek) → review+
Attached patch Patch v2Splinter Review
As before, except uses:
> ifneq (,$(findstring mingw,$(CONFIG_GUESS)))
...instead of:
> ifneq (,$(filter MINGW%,$(shell uname -s)))

Also replaces an existing MINGW check that can use CONFIG_GUESS as well, avoid shelling out there too.
Attachment #579193 - Attachment is obsolete: true
Flags: in-testsuite-
Target Milestone: --- → mozilla11
Closed: 12 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.