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']"

RESOLVED FIXED in mozilla11


8 years ago
a year ago


(Reporter: emorley, Assigned: emorley)



Windows 7

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



8 years ago
Posted 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

Comment 1

8 years ago
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.

Comment 2

8 years ago
Yes, pymake uses windows paths not msys paths. Feel free to make the error message reasonable.

Comment 3

8 years ago
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']"

Comment 4

8 years ago
Posted 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+

Comment 6

8 years ago
Posted 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

Comment 7

8 years ago
Flags: in-testsuite-
Target Milestone: --- → mozilla11

Comment 8

8 years ago
Last Resolved: 8 years ago
Resolution: --- → FIXED


a year ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.