867807 - "No rule to make target 'C:/Program'" while linking xul.dll (build works fine though)

Status: REOPENED

(Firefox Build System :: General, defect)

Description

[Frank Wein [:mcsmurf]]

I observed a possible build problem while linking xul.dll, I'm not sure though if this is actually a valid bug (as the build succeeds in the end).
I built SeaMonkey on Windows 8 with latest mozilla-build and VS 2012. I used the command "mozilla/mach build" to run the build (I expect to get the following warnings, too, when building Firefox, but I did not test). Then I noticed those warnings (errors?) while it was linking xul.dll:
202:29.53 No rule to make target 'C:/Program' needed by ['<command-line>', 'C:/P
rogram']
202:29.53 No rule to make target 'Files' needed by ['<command-line>', 'Files']
202:29.53 No rule to make target '(x86)/Microsoft' needed by ['<command-line>',
'(x86)/Microsoft']
202:29.54 No rule to make target 'DirectX' needed by ['<command-line>', 'DirectX
']
202:29.54 No rule to make target 'SDK' needed by ['<command-line>', 'SDK']
202:29.54 No rule to make target '(June' needed by ['<command-line>', '(June']
202:29.54 No rule to make target '2010)/Lib/x86/dxguid.lib' needed by ['<command
-line>', '2010)/Lib/x86/dxguid.lib']
202:29.54 No rule to make target '2010)/Lib/x86/dinput8.lib' needed by ['<comman
d-line>', '2010)/Lib/x86/dinput8.lib']
202:29.54 xul.dll
(yes, this is a slow machine)

In the end I got a xul.dll file anyway. But those warnings made we wonder if some quotes are missing somewhere. Or are those warnings(?) harmless in this case?

Comment 1

[Frank Wein [:mcsmurf]]

Looks like I cannot reproduce this with a Firefox mach build (at least no signs of those warnings in a log file created with "mach -l ff.log build"). I probably need to test again with a clean SeaMonkey build.

Comment 2

[Frank Wein [:mcsmurf]]

Resolving as wfm for now, I don't see this error anymore(?) in a build log. Strange.

Comment 3

[Frank Wein [:mcsmurf]]

I saw this happening again, it was not during linking libxul though, but while creating(?) libGLESv2.dll and libEGL.dll. This happened during a dep build with "mozilla/mach build":
 4:30.33 No rule to make target 'E:/Program' needed by ['<command-line>', 'E:/Program']
 4:30.33 No rule to make target 'Files' needed by ['<command-line>', 'Files']
 4:30.33 No rule to make target '(x86)/Microsoft' needed by ['<command-line>', '(x86)/Microsoft']
 4:30.33 No rule to make target 'DirectX' needed by ['<command-line>', 'DirectX']
 4:30.33 No rule to make target 'SDK' needed by ['<command-line>', 'SDK']
 4:30.33 No rule to make target '(June' needed by ['<command-line>', '(June']
 4:30.33 No rule to make target '2010)/lib/x86/d3d9.lib' needed by ['<command-line>', '2010)/lib/x86/d3d9.lib']
 4:30.33 No rule to make target '2010)/lib/x86/D3DCompiler.lib' needed by ['<command-line>', '2010)/lib/x86/D3DCompi
ler.lib']
 4:30.45 libGLESv2.dll
 4:31.19    Bibliothek "libGLESv2.lib" und Objekt "libGLESv2.exp" werden erstellt.
 4:31.19
 4:31.31 No rule to make target 'E:/Program' needed by ['<command-line>', 'E:/Program']
 4:31.31 No rule to make target 'Files' needed by ['<command-line>', 'Files']
 4:31.31 No rule to make target '(x86)/Microsoft' needed by ['<command-line>', '(x86)/Microsoft']
 4:31.31 No rule to make target 'DirectX' needed by ['<command-line>', 'DirectX']
 4:31.31 No rule to make target 'SDK' needed by ['<command-line>', 'SDK']
 4:31.31 No rule to make target '(June' needed by ['<command-line>', '(June']
 4:31.32 No rule to make target '2010)/lib/x86/d3d9.lib' needed by ['<command-line>', '2010)/lib/x86/d3d9.lib']
 4:31.32 No rule to make target '2010)/lib/x86/dxguid.lib' needed by ['<command-line>', '2010)/lib/x86/dxguid.lib']
 4:31.33 libEGL.dll

Comment 4

[Marco Bonardo [:mak]]

I can also reproduce this, though I didn't try to clobber yet, this bug is something we already hit in the past, even if then it was breaking the build while now it seems to have no effect.

IIRC Jeff was involved with those changes, I wonder if he may know if the original pymake issue with uncompressing those libraries still exists or just this output is expected and ignored on purpose.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

This output is not expected. I wonder if it was a regression from a more recent build change.

Comment 6

[Gregory Szorc [:gps]]

Paths with spaces won't work in make. It looks like somewhere there is a dependency on d3d9.lib and dxguid.lib. Since all prerequisites are potential targets, make is looking for a rule with this target name. Since values with spaces are interpreted as multiple values and since there is no rule for building these dependencies (because they are system files by the looks of it), make spews the output that it does.

This error should be harmless. But it would be nice to know where the dependencies are coming from so we can potentially scrub them.

Comment 7

[Avi Halachmi (:avih)]

FWIW, this still happens (and the build still works anyway):

30:04.01 No rule to make target 'C:/Program' needed by ['<command-line>', 'C:/Program']
30:04.01 No rule to make target 'Files' needed by ['<command-line>', 'Files']
30:04.01 No rule to make target '(x86)/Microsoft' needed by ['<command-line>', '(x86)/Microsoft']
30:04.01 No rule to make target 'DirectX' needed by ['<command-line>', 'DirectX']
30:04.01 No rule to make target 'SDK' needed by ['<command-line>', 'SDK']
30:04.01 No rule to make target '(June' needed by ['<command-line>', '(June']
30:04.01 No rule to make target '2010)/Lib/x86/dxguid.lib' needed by ['<command-line>', '2010)/Lib/x86/dxguid.lib']
30:04.01 No rule to make target '2010)/Lib/x86/dinput8.lib' needed by ['<command-line>', '2010)/Lib/x86/dinput8.lib']
30:04.07 xul.dll
30:48.58    Creating library xul.lib and object xul.exp
30:48.58
30:48.58 LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
30:48.58

Comment 8

[Mark Hammond [:markh] [:mhammond]]

I can confirm this happens when the DirectX SDK is installed to a dir with a space in the path, and goes away if it is reinstalled to a path with no space.

A side-effect of this is that the build system never things xul.dll is up-to-date, so any time toolkit/library is rebuilt (either directly as a specified target, or indirectly if the build system knows to rebuild that when another directory is rebuilt), the DLL gets rebuilt, adding a number of minutes to what should be a no-op.

Comment 9

[Mike Hommey [:glandium]]

Arguably, that dependency is useless.

Comment 10

[Avi Halachmi (:avih)]

(In reply to Mark Hammond [:markh] from comment #8)
> I can confirm this happens when the DirectX SDK is installed to a dir with a
> space in the path, and goes away if it is reinstalled to a path with no
> space.

I've installed the SDK some time ago, but isn't "c:\Program Files\..." (which has a space) the default path on systems with English locale, making it quite a common case?

Comment 11

[Mark Hammond [:markh] [:mhammond]]

(In reply to Avi Halachmi (:avih) from comment #10)
> I've installed the SDK some time ago, but isn't "c:\Program Files\..."
> (which has a space) the default path on systems with English locale, making
> it quite a common case?

Yes, that's true.  I typically change the install path for these SDKs etc (just so they are easier to get to from the cmdline for grepping headers, etc), but I didn't do this on my laptop and struck this there.

Comment 12

[Masatoshi Kimura [:emk]]

(In reply to Mark Hammond [:markh] from comment #8)
> A side-effect of this is that the build system never things xul.dll is
> up-to-date, so any time toolkit/library is rebuilt (either directly as a
> specified target, or indirectly if the build system knows to rebuild that
> when another directory is rebuilt), the DLL gets rebuilt, adding a number of
> minutes to what should be a no-op.

Oh, is this the cause of bug 876566?

Comment 13

[Mark Hammond [:markh] [:mhammond]]

(In reply to Masatoshi Kimura [:emk] from comment #12)
 
> Oh, is this the cause of bug 876566?

Possibly (even probably :) although it seems impossible to know for sure given the information in that bug.  As I'm sure you've seen by now, I've commented there...

Comment 16

[Ziga Seilnacht]

Attachment: filter out dependencies with spaces in path in makeutil

The warning is reported only on non-clobber builds, it is caused by expandlibs_exec.py not filtering the dependencies that it writes.

Would it be OK to move filtering of paths with spaces from mozbuild.action.cl to mozbuild.makeutil? The attached patch does that and gets rid of the warning and relinking. With this patch applied, no-op `mach build binaries` goes from 1:15s to 15s for me.

Comment 17

[Ziga Seilnacht]

Oh, and bug 938721 seems to be another duplicate of this bug.

Comment 18

[Mike Hommey [:glandium]]

Comment on attachment 833209 [details] [diff] [review]
filter out dependencies with spaces in path in makeutil

Review of attachment 833209 [details] [diff] [review]:
-----------------------------------------------------------------

cl.py should still do its filtering, and makeutil should escape spaces with a backslash instead of removing the files containing them.