965106 - Normalize paths returned with os.getcwd() on Windows

Status: NEW

(Firefox Build System :: General, defect)

Description

[Honza Bambas (:mayhemer)]

Long time ago I've hit this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=824004#c43

Now it returns to me after I started to build from VS IDE: http://www.janbambas.cz/building-mozilla-code-directly-from-visual-studio-ide/

When a moz.build file is changed, then |mach build binaries| regenerates the backend.  And when run from the IDE it again sticks the upper case C: to path references on few places in the obj tree what breaks the build again (this time with 'RegisterBindings.cpp(481) : error C2653: 'CSS2PropertiesBinding' : is not a class or namespace') - clobber is then needed.

I've checked how often we use os.getcwd(), and it really is on a lot of places.

The options are:
- change all of them
- change only the one or few causing the problems (no idea which those are)
- alter the Python's os.getcwd function with our own (overload) on Win

Comment 1

[Gregory Szorc [:gps]]

See also bug 836889.

Comment 2

[Gregory Szorc [:gps]]

So, Visual Studio is using "C" but the command line is using "c".

I read through bug 836889 and it isn't clear what we should normalize to.  I would have guessed lower case. But you said Visual Studio is inserting upper case. I'd like to think we should emulate the "native" tools.

So confusing.

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Gregory Szorc [:gps] from comment #2)
> So, Visual Studio is using "C" but the command line is using "c".
> 
> I read through bug 836889 and it isn't clear what we should normalize to.  I
> would have guessed lower case. But you said Visual Studio is inserting upper
> case. I'd like to think we should emulate the "native" tools.
> 
> So confusing.

Until you do |$cd something| in your bash, os.getcwd() returns 'C'.  But after you do, it returns 'c'.  I don't know why exactly at the moment.

My tendency to lowercase is coming from fact that I discovered/first hit this bug a long ago before playing with VS IDE builds.  I have slightly modified my start-msvc.bat files to not change dir to home but stay where it was ran from (I use Total Commander.  ) Every one else is using the unmodified files, so they MUST cd to the mozilla source dir first before any buils can be done.  So they actively mitigate this bug every time.  Today I'm used to do cd build && cd .. when I start my bash to prevent these problems.  But from VS IDE I cannot do |cd whatever| before the build, so it breaks again.

I haven't tried for some time to do a clobbered build w/o the "cd fix" and then do binaries on it, run tests, build only one module or so and also build from the IDE.  I can try to do that.

Comment 4

[Gregory Szorc [:gps]]

What exactly are the build failures? Is this something we could fix in pymake / gnu make by making drive letters case insensitive? Are you using mozmake.exe or still using pymake?

Comment 5

[Honza Bambas (:mayhemer)]

(In reply to Gregory Szorc [:gps] from comment #4)
> What exactly are the build failures? 

The latest I'm hitting is:

'RegisterBindings.cpp(481) : error C2653: 'CSS2PropertiesBinding' : is not a class or namespace'

during build of dom/bindings


A time ago:

NSS build failed since some strange src dir replacement in the path at [1] didn't work.  I was trying to fix it in the makefile, but I failed (not an expert for Make).



> Are you using
> mozmake.exe or still using pymake?

mozmake, and I think pymake used to have similar issues. 



[1] http://hg.mozilla.org/mozilla-central/annotate/b28e216c8d07/security/build/Makefile.in#l151

Comment 6

[Gregory Szorc [:gps]]

The *Binding errors /could/ be a regression from recent WebIDL refactor. Related to this case issue, sure.

glandium: what do you know about GNU make and drive letter case sensitivity?

Also, I'm very tempted to dupe this on 836889. Too many bugs with similar discussions going on...

Comment 7

[Michael Shal [:mshal]]

(In reply to Gregory Szorc [:gps] from comment #6)
> glandium: what do you know about GNU make and drive letter case sensitivity?

In the NSS build system, we hit a problem because it was using $(subst) to cut out part of a path, but one path used "c:" and another used "C:". So it was a problem of using a case-sensitive string matching function on paths that are supposed to be case-insensitive (bug 963123). That was just one specific instance - I'm sure each one is unique :)

> 
> Also, I'm very tempted to dupe this on 836889. Too many bugs with similar
> discussions going on...

I think you mean bug 846889?

Comment 8

[Honza Bambas (:mayhemer)]

(In reply to Michael Shal [:mshal] from comment #7)
> I think you mean bug 846889?

Oh!  I completely forgot about that bug :)  It's similar, just a bit more mess I think.  It was reported sooner the getcwd()/cd problem was identified.

Comment 9

[Mike Hommey [:glandium]]

(In reply to Gregory Szorc [:gps] from comment #6)
> glandium: what do you know about GNU make and drive letter case sensitivity?

Nothing besides what i wrote in bug 824004 comment 43

Comment 10

[Mike Hommey [:glandium]]

From some testing, it appears drive letter case matters in both dependencies and command line. However, it doesn't matter if the drive letter case matches that of $(CURDIR).