846889 - python -c 'import os;print os.getcwd()' returns drive letter capitalized until cd

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Honza Bambas (:mayhemer)]

STR for me:
- win7, latest mozilla-build at c:/Mozilla/mozilla-build
- working build env, vc10
- clone tree
- export MOZCONFIG=/c/Mozilla/confs/bd [1]
- optionally: qpush any local patches I work on
- mach build
- build usually works
- export MOZCONFIG=/c/Mozilla/confs/bo [2]
- mach build
- build usually works
- qpop all patches
- pull, update to default
- clobber all (both) my in-src _obj-* dirs
- export MOZCONFIG=/c/Mozilla/confs/bd
- mach build
=> hit bug 824004

- fix bug 824004 (by capitalizing drive letter in ABS_topsrcdir make variable used to build NSS)
=> hit bug 846857

So, I'm pretty stuck.  Better word: despaired.

Few notes:
- moving _obj dir out of the src tree doesn't have affect
- changing name of obj dirs doesn't have affect
- I don't want to change names and location of my _obj dirs, since it doesn't change anything anyway
- cleaning all .pyc files from the source tree doesn't help



[1] (bd - stands for Browser Debug config)
# Options for client.mk.
mk_add_options MOZ_OBJDIR=_obj-browser-debug
mk_add_options MOZ_MAKE_FLAGS=-j9

# Options for 'configure' (same as command-line options).
#ac_add_options --enable-jemalloc

export MOZ_DEBUG_SYMBOLS=1

ac_add_options --enable-application=browser
ac_add_options --enable-debug
ac_add_options --disable-optimize
ac_add_options --enable-shared

ac_add_options --disable-static
ac_add_options --enable-tests
ac_add_options --enable-logging
ac_add_options --enable-visual-event-tracer
ac_add_options --disable-installer
ac_add_options --enable-chrome-format=flat
ac_add_options --disable-crashreporter
#ac_add_options --disable-webm
ac_add_options --disable-accessibility
#ac_add_options --disable-webgl
#ac_add_options --disable-ogg
#ac_add_options --disable-webrtc
#ac_add_options --disable-dash 


[2] (bo - stands for Browser Optimized config)
# http://mxr.mozilla.org/build/source/buildbot-configs/mozilla2/win32/mozilla-central/unittest/mozconfig?raw=1
# For NSS symbols
mk_add_options MOZ_OBJDIR=_obj-browser-opt
mk_add_options MOZ_MAKE_FLAGS=-j9



export MOZ_DEBUG_SYMBOLS=1

ac_add_options --enable-application=browser
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-logrefcnt


ac_add_options --enable-tests
ac_add_options --enable-logging
ac_add_options --enable-visual-event-tracer


ac_add_options --disable-installer
ac_add_options --disable-crashreporter
#ac_add_options --disable-webm
ac_add_options --disable-accessibility
#ac_add_options --disable-webgl
#ac_add_options --disable-ogg
#ac_add_options --disable-webrtc
#ac_add_options --disable-dash

Comment 1

[Gregory Szorc [:gps]]

Possible workaround: define MOZ_OBJDIR in terms of @TOPSRCDIR@ in your mozconfig. e.g.

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox


Is this a regression from bug 784841? Either way, we could throw a few more normpath() in config.status and elsewhere. And, we could catch invalid paths earlier in the build.

Comment 2

[Honza Bambas (:mayhemer)]

(In reply to Gregory Szorc [:gps] from comment #1)
> Possible workaround: define MOZ_OBJDIR in terms of @TOPSRCDIR@ in your
> mozconfig. e.g.
> 
> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox
> 
> 
> Is this a regression from bug 784841? Either way, we could throw a few more
> normpath() in config.status and elsewhere. And, we could catch invalid paths
> earlier in the build.

Forgot to add a note:
- and adding @TOPSRCDIR@ to MOZ_OBJDIR doesn't help

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Gregory Szorc [:gps] from comment #1)
> Is this a regression from bug 784841? 

No idea.  I started to have problem after bug 486141 has landed (https://hg.mozilla.org/mozilla-central/rev/ba511a01e9c7, on  2012-12-12)


> Either way, we could throw a few more
> normpath() in config.status and elsewhere. And, we could catch invalid paths
> earlier in the build.

I can test, since I have the tree in the unbuildable state.

What should I do?

Comment 4

[Gregory Szorc [:gps]]

Oh, I didn't really look at the other bugs when I wrote my first comment. I'm pretty sure this is an outstanding issue.

Normalizing paths on Windows is a crap shoot. We probably have a few dozen little bugs like this.

Comment 5

[Honza Bambas (:mayhemer)]

Yes, but what can I do right now?  I cannot work, I'm completely stuck!!!

Comment 6

[Honza Bambas (:mayhemer)]

BTW, I think it has something to do with two obj dirs.  I don't remember (however I might be wrong) any issues mentioned here would happen when I was not building also the opt config.

Comment 7

[Mike Hommey [:glandium]]

https://bugzilla.mozilla.org/show_bug.cgi?id=824004#c25

Comment 8

[Honza Bambas (:mayhemer)]

Forgot to add you, jesup...

Comment 9

[Honza Bambas (:mayhemer)]

Potential workaround: update to a changeset that modified the clobber file, try to build with 'mach build', get the 'clobber needed' error, delete obj dir, build again.

Comment 10

[Honza Bambas (:mayhemer)]

Comment 9 doesn't work.

When I hit this (these) bug(s) today, I fixed that by deleting the configure file under the source tree.  Not sure if applying patch [1] or restarting the machine had some effect, probably not, now I'm build w/o the patch well.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=824004#c32

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to Mike Hommey [:glandium] from bug 824004 comment #43)
> So, turns out there's something fishy with python on windows:
> 
> $ python -c 'import os;print os.getcwd()'
> C:\Users\mh
> 
> $ cd mozilla-central/
> 
> $ python -c 'import os;print os.getcwd()'
> c:\Users\mh\mozilla-central
> 
> $ cd ..
> 
> $ python -c 'import os;print os.getcwd()'
> c:\Users\mh

Comment 12

[(not currently active) Ted Mielczarek]

Since the behavior here appears to be insane, we should just normalize the topsrcdir path when we substitute it into Makefiles.

Comment 13

[Mike Hommey [:glandium]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #12)
> Since the behavior here appears to be insane, we should just normalize the
> topsrcdir path when we substitute it into Makefiles.

As things would likely break if we'd normalize the entire path, we should probably just normalize the drive letter.

Comment 14

[(not currently active) Ted Mielczarek]

This was hit in bug 963123 as well, causing NSS build failures on new build slaves.

Comment 16

[Gregory Szorc [:gps]]

mayhemer: is this still a valid bug? There's a chance we flushed this out recently.

Comment 17

[Honza Bambas (:mayhemer)]

I haven't seen the issue on an hg repo build.