Bug 146877 – Build failure with: No rule to make target '...Release/include/private/JavaScriptCore/JSInputs.json', needed by 'WebReplayInputs.h'. Stop.

• Component: Tools / Tests
• Status: RESOLVED INVALID

[Simon Fraser (smfr)]

My Mac build often fails with this error the first time, then builds a second time.

Windows is now also showing this same error: https://webkit-queues.appspot.com/results/6038448339156992

  make: *** No rule to make target '/home/buildbot/WebKit/WebKitBuild/Release/include/private/JavaScriptCore/JSInputs.json', needed by 'WebReplayInputs.h'.  Stop.

Seems like there's a dependency issue with JSInputs.json and WebReplayInputs.h.

[Brian Burg]

Not sure what changed, I will not have access to a dev machine until the 15th at the earliest. Have you tried a clean build?

[Simon Fraser (smfr)]

The point is that this sporadically breaks incremental builds, meaning it affects EWS etc.

[Simon Fraser (smfr)]

This just broke my local build.

[Joseph Pecoraro]

(In reply to comment #0)
> My Mac build often fails with this error the first time, then builds a
> second time.
> 
> Windows is now also showing this same error:
> https://webkit-queues.appspot.com/results/6038448339156992
> 
>   make: *** No rule to make target
> '/home/buildbot/WebKit/WebKitBuild/Release/include/private/JavaScriptCore/
> JSInputs.json', needed by 'WebReplayInputs.h'.  Stop.

JSInputs.json is just copied to Private Headers on Mac. It does not need to be generated at all. It sounds like this build error is saying JSInputs.json doesn't exist, so for some reason it wasn't copied earlier?

[Joseph Pecoraro]

Same thing for Windows:

Source/JavaScriptCore/JavaScriptCore.vcxproj/copy-files.cmd copies the JSInputs.json as a private headers:

    echo Copying Web Replay specification files as if they were private headers...
    @xcopy /y /d ..\replay\*.json "%PrivateHeadersDirectory%" >NUL

And then WebCore's Derived Sources attempts to use it as expected:

    INPUT_GENERATOR_SPECIFICATIONS = \
    	$(WebCore)/replay/WebInputs.json \
    	$(WebReplayScripts)/JSInputs.json \
    #

    all : WebReplayInputs.h

    WebReplayInputs.h : $(INPUT_GENERATOR_SPECIFICATIONS) $(INPUT_GENERATOR_SCRIPTS)
    	$(PYTHON) $(WebReplayScripts)/CodeGeneratorReplayInputs.py --outputDir . --framework WebCore $(INPUT_GENERATOR_SPECIFICATIONS)

On Windows the $(WebReplayScripts) build variable is setup to point to what looks like the right place:

    WebCore.vcxproj/build-generated-files.pl
    76:$ENV{'WebReplayScripts'} = File::Spec->catdir($XDSTROOT, 'include', 'private', 'JavaScriptCore');

That said, WebCore's `make-generated-sources.sh` meant for manually invoking DerivedSources wouldn't work as is, since the scripts and JSON input are in different places in the source directory:

    make-generated-sources.sh
    6:export WebReplayScripts=$PWD/../JavaScriptCore/replay/scripts

So, other than a possible issue with this script, the regular order of build operations looks reasonable to me.

[Brian Burg]

Simon, can you check whether this file actually exists prior to and after the failed build? If it's not obvious what's going on, you can use DTrace to see what files are touched during the build:

# Files opened by process,
dtrace -n 'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }'

[Simon Fraser (smfr)]

This happened again.

When it happened, OpenSource/WebKitBuild/Debug/JavaScriptCore.framework/PrivateHeaders was a broken symlink:

lrwxr-xr-x   1 smfr  staff    31 Jul  6 12:05 PrivateHeaders -> Versions/Current/PrivateHeaders
 16$ $ ls -la /Volumes/Data/Development/OSX/webkit/OpenSource/WebKitBuild/Debug/JavaScriptCore.framework/Versions/Current/
total 0
drwxr-xr-x  3 smfr  staff  102 Jul 16 20:37 .
drwxr-xr-x  3 smfr  staff  136 Jul 16 20:37 ..
drwxr-xr-x  2 smfr  staff  102 Jul 16 20:37 Resources

[Alexey Proskuryakov]

There have certainly been script changes lately WRT JavaSriptCore symlinks.

This was caused by an issue in the version of Xcode Simon was using, <rdar://problem/22081897>.