Substitute windows-style paths in configure when building with pymake

RESOLVED FIXED in mozilla1.9.3a1

Status

Firefox Build System
General
RESOLVED FIXED
9 years ago
2 months ago

People

(Reporter: Benjamin Smedberg, Assigned: Benjamin Smedberg)

Tracking

Trunk
mozilla1.9.3a1
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(status1.9.2 .4-fixed)

Details

(Whiteboard: partial fix on 1.9.2 branch [qa-noaction-192])

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

9 years ago
Created attachment 369556 [details] [diff] [review]
Hack configure to accept windows-style absolute paths, rev. 1

When configure is called with a Windows-style absolute path, as it is with pymake, there are some minor adjustments that must be made:

* configure uses : as a separator by default. We rewrite autoconf macros to avoid this
* configure detects absolute paths using a glob /* . We rewrite autoconf macros to avoid this
* MSYS perl expects MSYS paths everywhere, and can't deal with windows-style paths at all. We use a wrapper to get around this until we can excise perl entirely
* use $(abspath) in a few Windows-only codepaths to get the right directory style

If this patch is acceptable, I have a matching NSPR version.
Attachment #369556 - Flags: review?(ted.mielczarek)
(Assignee)

Updated

9 years ago
Blocks: 485412
(Assignee)

Comment 1

9 years ago
Comment on attachment 369556 [details] [diff] [review]
Hack configure to accept windows-style absolute paths, rev. 1

This is slightly borken, please hold off reviewing it.
Attachment #369556 - Flags: review?(ted.mielczarek)
(Assignee)

Comment 2

9 years ago
Created attachment 370676 [details] [diff] [review]
Hack configure to accept windows-style absolute paths, rev. 1.1
Attachment #369556 - Attachment is obsolete: true
Attachment #370676 - Flags: review?(ted.mielczarek)
Comment on attachment 370676 [details] [diff] [review]
Hack configure to accept windows-style absolute paths, rev. 1.1

FWIW, I reviewed most of this by generating configure before/after this patch, then running both copies through `sed -re "s/^#line [0-9]+/#line /" -e "s/configure:[0-9]+:
/configure:/"` to get rid of line number differences.

+++ b/build/msys-perl-wrapper

This is kind of gross, but I guess we don't have any other choices until we ditch perl completely, eh?

     dnl MinGW/MSYS does not need CYGWIN_WRAPPER
+        PERL="/bin/sh ${srcdir}/build/msys-perl-wrapper"

Perhaps add a more descriptive comment there?

 ifeq (,$(filter-out WINNT WINCE,$(OS_ARCH)))
-_VPATH_SRCS = $(if $(filter /%,$<),$<,$(CURDIR)/$<)
+_VPATH_SRCS = $(abspath $<)
 else
 _VPATH_SRCS = $<
 endif

Can we just use core_abspath there and ditch the ifdef?

Otherwise, looks as good as a patch full of m4 can look.
Attachment #370676 - Flags: review?(ted.mielczarek) → review+
I decided against changing that, since it'd change behavior and I wasn't 100% sure on it. Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/1c4751f81b1d
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
This change appears to have broken all my object directories. I have them set them up as sibling directories of the source directories. Here's how I set one up:
MOZCONFIG=../mozconfig ../mozilla-central/configure && make -s -j2

The build complains about being unable to find ../mozilla-central/build/msys-perl-wrapper despite the fact that it seems to exist - I suspect that the relative path is to blame since when I run:
MOZCONFIG=../mozconfig /c/Users/Rob/mozilla/mozilla-central/configure && make -s -j2

It appears to build just fine (build hasn't finished yet, but it appears to have made more progress).

Is there any chance that this can be fixed to work with relative paths?
Oh, I should not that I am not using pymake.
(Assignee)

Comment 8

9 years ago
That's bug 518401
Depends on: 524785
(In reply to comment #0)
> If this patch is acceptable, I have a matching NSPR version.

Did you ever find what happened to that patch? We still need it.

Updated

8 years ago
Blocks: 550657
Flags: in-testsuite-
Version: unspecified → Trunk
Created attachment 435819 [details]
Dummy file for changeset f655090e14c3 approval

Requesting approval for changeset http://hg.mozilla.org/mozilla-central/rev/f655090e14c3 to land on 1.9.2

Low risk, helps Comm-Central.
Attachment #435819 - Flags: approval1.9.2.3?
Comment on attachment 435819 [details]
Dummy file for changeset f655090e14c3 approval

unorthodox, but approved for 1.9.2.4, a=dveditz
Attachment #435819 - Flags: approval1.9.2.4? → approval1.9.2.4+
Comment on attachment 435819 [details]
Dummy file for changeset f655090e14c3 approval

Pushed as: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2b486c962f2f

(Bug is not 1.9.2 fixed, just this VERY minor followup is.)
(In reply to comment #13)
> (Bug is not 1.9.2 fixed, just this VERY minor followup is.)

status of the bug is splitted this way, should it be marked wontfix on 1.9.2 since it's not fixed and looks like there is no will to do that? having an approval but not having a status pollutes searches, the patch should have got its own bug.
(In reply to comment #14)
> (In reply to comment #13)
> > (Bug is not 1.9.2 fixed, just this VERY minor followup is.)
> 
> status of the bug is splitted this way, should it be marked wontfix on 1.9.2
> since it's not fixed and looks like there is no will to do that? having an
> approval but not having a status pollutes searches, the patch should have got
> its own bug.

IMO its not worth its own bug either; I did not update status as I don't even think that its needed to show up on 1.9.2-based searches. But if you want a bug to track it I won't stop you from filing one with appropriate status/settings/keywords etc.
(In reply to comment #15)
> IMO its not worth its own bug either; I did not update status as I don't even
> think that its needed to show up on 1.9.2-based searches.

the point is not if it should appear in 1.9.2 based searches, the point is that it appears in 1.9.2 searches as "with approval, but not landed"
I guess "wontfix" is closer to the truth than .4-fixed.
status1.9.2: --- → wontfix
Nope, that didn't clean up the query. Let's try fixed+whiteboard comment.
status1.9.2: wontfix → .4-fixed
Whiteboard: partial fix on 1.9.2 branch
thanks, appreciate it.
Whiteboard: partial fix on 1.9.2 branch → partial fix on 1.9.2 branch [qa-noaction-192]

Updated

8 years ago
Blocks: 566167

Updated

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