Bug ID: JDK-8123054 Gradle build system doesn't do partial build if native code is changed

JDK 8
8Fixed

I have filed RT-35065 for the JNI headers issue and assigned it to Felipe as he was the last to touch this code. RT-35066 tracks the recompilation of modified files.
19-12-2013
I saw the JNI problem and I thought it was something I did. I can confirm that it failed for me.
19-12-2013
Latest observations (tested on Windows): 1. If I only change a single file in Glass native sources, all the native Glass files get recompiled at once. Can this be improved to only recompile the files that have actually changed? (yes, I know there's an issue with headers, but currently I'm talking about .cpp/.c files). 2. JNI headers are not re-generated after I change a .java file that normally generates a header file. This is a bug that needs fixing.
19-12-2013
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2c0a00f8de4a
01-12-2013
Version 4 looks good to me. I reviewed the webrev and also ran various tests: open & closed builds, with / without purging, with / without clean. +1
27-11-2013
I'll take a look at the latest version tomorrow.
27-11-2013
Thanks for testing Chien. Kevin, I would like to get your blessing before I push this one if possible.
27-11-2013
+1. I have verified partial build works for me on either .cc, .h or .hlsl changed.
26-11-2013
I have tested the following cases gradle clean gradle sdk change /rt/modules/graphics/src/main/native-font/directwrite.cpp gradle change /rt/modules/graphics/src/main/native-prism-sw/JAbstractSurface.h gradle change /rt/modules/graphics/src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl gradle hg revert -C . gradle They all worked as expected with the last patch. Please review. Note the -C passed for revert, it stops revert from creating .orig which can change the list of files being compiled. For example, reverting directwrite.cpp creates directwrite.cpp.orig. NativeCompileTask will see that directwrite.cpp.orig and it will treat as 'resource file changed' case and build all the files in :graphics:font (as opposite of building only directwrite.cpp).
26-11-2013
Here is a single webrev http://cr.openjdk.java.net/~fheidric/RT31360-v4/webrev/ with all the changes.
26-11-2013
To make gradle build generateD3DHeaders only when require we need to set the inputs and outputs for the task: http://www.gradle.org/docs/current/userguide/more_about_tasks.html#sec:up_to_date_checks Here is the fix for generateD3DHeaders $ hg diff diff -r 43945f3bae30 build.gradle --- a/build.gradle Mon Nov 25 16:31:03 2013 -0800 +++ b/build.gradle Tue Nov 26 10:13:08 2013 -0800 @@ -1138,6 +1138,11 @@ task generateD3DHeaders(group: "Build") { enabled = IS_WINDOWS dependsOn javahWinPrismD3D + inputs.file "src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl" + inputs.file "src/main/native-prism-d3d/hlsl/Mtl1VS.hlsl" + inputs.file "src/main/native-prism-d3d/PassThroughVS.hlsl" + outputs.dir "$buildDir/headers/PrismD3D/" + outputs.dir "$buildDir/headers/PrismD3D/hlsl/" description = "Generate headers by compiling hlsl files" doLast { mkdir file("$buildDir/headers/PrismD3D/hlsl") ------------------------------------ As for the bad relation between ccWinPrismD3D and generateD3DHeaders I think we got lucky, the input files for generateD3DHeaders are also input files for ccWinPrismD3D, and all 3 input files for generateD3DHeaders are .hlsl, changing them will cause a fullBuild of ccWinPrismD3D (thanks to http://cr.openjdk.java.net/~fheidric/RT31360-v2/webrev/).
26-11-2013
Note, I still have a bad relation between ccWinPrismD3D and generateD3DHeaders. generateD3DHeaders always builds (as @inputFile is not set), and it starts ccWinPrismD3D, but it finds no work to do (as it does not track changes "build/headers/PrismD3D", which is produced by generateD3DHeaders). The fix is to only run generateD3DHeaders when needed (easy), and if generateD3DHeaders runs then run ccWinPrismD3D with "forceCompile=true".
26-11-2013
Sorry Kevin, I should have mention that: You need to apply http://cr.openjdk.java.net/~fheidric/RT31360-v2/webrev/ first and then apply http://cr.openjdk.java.net/~fheidric/RT31360-v3/webrev/ on top.
26-11-2013
BTW, instead of cleanNativePrismD3D I created Visual Studio project file with identical settings and paths, and I'm very happy to be able to hit F7 and it builds instantly. If anyone is interested, I could share it (although it's 2012 version)
26-11-2013
I tried to run it, but the patch doesn't apply cleanly for me. I didn't have time today to look further.
26-11-2013
Here is a fix for problem 2: http://cr.openjdk.java.net/~fheidric/RT31360-v3/webrev/ Note that I don't need to remove the fileData from dependencies if "doCompile(sourceFile, outputFile)" fails. If a problem happens the call to "futures.each {it.get();}" will throw, and dependencies will not be written to nativeDependenciesFile.
26-11-2013
Please err on the side of building too much rather than too little. File JIRA for any work items that are left to do,
25-11-2013
I agree, doing this alone is a good step forward. It eliminates the need to manually call cleanNativePrismD3D whenever there is a native d3d change.
25-11-2013
At list 2 problem in there: 1) generateD3DHeaders should happen when any of these files are modified: file("src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl") file("src/main/native-prism-d3d/hlsl/Mtl1VS.hlsl") file("src/main/native-prism-d3d/PassThroughVS.hlsl") 2) The code that check if file.c to file.o has to happen doesn't know anything about headers files... I don't think we can use makedepend. First, I think it requires a makefile for it to work. Second, too late in the game. My suggestion is to build all native files if any header file/resource file is changed.
25-11-2013
FWIW, we've used the makedepend utility in the old build system (ant/Makefile based) to detect changes in header files and recompile only relevant native source files. At least we did it in Glass. And it worked awesomely. If Gradle doesn't have support for this (which I doubt it has), we could start using makedepend again.
25-11-2013
It seems that it doesn't detect header files changes. First, if I change for example rt\modules\graphics\src\main\native-prism-d3d\hlsl\Mtl1PS.hlsl This unconditially compiles to the bunch of headers in the rt\modules\graphics\build\headers\PrismD3D\hlsl which are included in the rt\modules\graphics\src\main\native-prism-d3d\D3DPhongShaderGen.cc So it should be compiled, but all I can see is :graphics:ccWinPrismD3D :graphics:rcPrismD3D :graphics:linkWinPrismD3D UP-TO-DATE :graphics:nativePrismD3D UP-TO-DATE If I change some header in the native-prism-d3d, it behaves the same, only if I change the source file, it recompiles only the changed file and links the native dll The debug log shows that it actually detect changes, but doesn't compile needed files: 14:00:54.138 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Executing task ':graphics:ccWinPrismD3D' (up-to-date check took 0.017 secs) due to: Input file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DContext.h has changed. 14:00:54.138 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':graphics:ccWinPrismD3D'. ...DefaultLoggingConfigurer skipped... 14:00:54.217 [INFO] [org.gradle.api.Project] Compiling native files: [C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DContext.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DContextInit.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DGraphics.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DLight.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DMesh.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DMeshView.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DPhongMaterial.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DPhongShader.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DPhongShaderGen.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DPipeline.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DPipelineManager.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DResourceFactory.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DResourceManager.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DShader.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\TextureUploader.cc, C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\Trace.cc] ...DefaultLoggingConfigurer skipped... 14:00:54.541 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:ccWinPrismD3D' 14:00:54.541 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:ccWinPrismD3D (Thread[main,5,main]) completed. Took 0.421 secs. 14:00:54.542 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:rcPrismD3D (Thread[main,5,main]) started. 14:00:54.542 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:rcPrismD3D 14:00:54.542 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':graphics:rcPrismD3D' 14:00:54.542 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Determining if task ':graphics:rcPrismD3D' is up-to-date 14:00:54.554 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Executing task ':graphics:rcPrismD3D' (up-to-date check took 0.012 secs) due to: Input file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\src\main\native-prism-d3d\D3DContext.h has changed. 14:00:54.554 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':graphics:rcPrismD3D'. ...DefaultLoggingConfigurer skipped... 14:00:54.566 [INFO] [org.gradle.api.Project] Compiling native files: [] ...DefaultLoggingConfigurer skipped... 14:00:54.859 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:rcPrismD3D' 14:00:54.859 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:rcPrismD3D (Thread[main,5,main]) completed. Took 0.317 secs. 14:00:54.859 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:linkWinPrismD3D (Thread[main,5,main]) started. 14:00:54.859 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:linkWinPrismD3D 14:00:54.859 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':graphics:linkWinPrismD3D' 14:00:54.859 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Determining if task ':graphics:linkWinPrismD3D' is up-to-date 14:00:54.863 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Skipping task ':graphics:linkWinPrismD3D' as it is up-to-date (took 0.003 secs). 14:00:54.863 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:linkWinPrismD3D' 14:00:54.864 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:linkWinPrismD3D UP-TO-DATE 14:00:54.864 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:linkWinPrismD3D (Thread[main,5,main]) completed. Took 0.005 secs. 14:00:54.864 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:nativePrismD3D (Thread[main,5,main]) started. 14:00:54.864 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:nativePrismD3D 14:00:54.864 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':graphics:nativePrismD3D' 14:00:54.864 [INFO] [org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter] Skipping task ':graphics:nativePrismD3D' as it has no actions. 14:00:54.864 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:nativePrismD3D' 14:00:54.864 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:nativePrismD3D UP-TO-DATE 14:00:54.864 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:nativePrismD3D (Thread[main,5,main]) completed. Took 0.0 secs. If the source file is changed, the difference is that it actually execute compiler after the "Compiling native files", but it compiles only the changed file and doesn't detect dependencies if the header was changed. Hope this helps!
25-11-2013
Version 2 - http://cr.openjdk.java.net/~fheidric/RT31360-v2/webrev/ Please try it out. Notes: 1. In compile() I could have tried to be smarter and only add to allFiles and entries that are in sourceRoots but not in allFiles, but I decided for the dumb/safer redo the whole list code. 2. Another option to fix this bug is to add a 'isStableInput()' to NativeCompileTask which returns true and is overwritten in CompileHLSLTask to return false. Then isStableInput() is true allFiles is init in source(), if false in compile() Anyway, I suggesting (1) as it is a less intrusive change. 3. You will also note that I added a extra check: "file && file.exists()" before touching an element from sourceRoots. I was getting weird error during 'clean'. Sometimes it happens (I suspect) because there is lock in the file getting delete but I also think were were calling "file.isDirectory()" when file was NULL in other cases.
23-11-2013
The main difference about HLSL files is that their input are generated files, stored in rt/modules/graphics/build/generated-src/jsl-$lowerName/$pkg (the output is stored in rt\modules\graphics\build\hlsl) If you delete rt\modules\graphics\build you are deleting the input files for CompileHLSLTask, thus the allFiles is empty. If you delete rt\modules\graphics\build\hlsl you are only deleting output of CompileHLSLTask and allFiles list is correctly populate with the content from the input folder. Now, the why 'gradle clean sdk' works and 'gradle clean; gradle sdk' does not: I think that is because gradle has two phases, configure tasks and execute tasks. In the first case, when the CompileHLSLTask tasks are being configured the rt/modules/graphics/build/generated-src/jsl-$lowerName/$pkg has not yet being delete, so allFiles is getting the good stuff. The problem is that before the patch allFiles was being computed during "execution time", after the patch it changed to "configure time". I think the fix is to compute allFiles during "configure time" (as the patches), and during "execution time" it needs to re-validate the sourceRoots to make sure nothing is changed, does that sound right ?
22-11-2013
We are all using gradle 1.8, right?
22-11-2013
I confirm that with a freshly cloned repo I reproduce the failure. Note: I do clone rt-closed, so this is not an OpenJFX build.
22-11-2013
Btw, on a possibly related note, I question why Decora JSL sources are processed by buildSrc. The decora compiler itself is a build tool, and is (correctly) done in the buildSrc step, but the .jsl files are source code and should be compiled into glsl or hlsl as part of the graphics project. Too late to change this for FX 8, but possibly something to think about for the future.
22-11-2013
Thanks, Vadim. This should be a useful clue for Felipe.
22-11-2013
More quick tests: If I remove whole rt\modules\graphics\build directory and do simple gradle, then I won't get hlsl compiled, but the empty hlsl folder will be created If I remove this empty folder rt\modules\graphics\build\hlsl and invoke gradle again, the shaders will be compiled
22-11-2013
more than that, I can do gradle clean gradle many times and there will be no hlsl shaders compiled but as soon as I do gradle gradle clean sdk then they are compiled So basically there must be build folders present and the build must be started with gradle clean sdk to succeed for me.
22-11-2013
If I do gradle clean sdk then the --info log looks like this: :graphics:compileDecoraHLSLShaders (Thread[main,5,main]) started. :graphics:compileDecoraHLSLShaders Executing task ':graphics:compileDecoraHLSLShaders' (up-to-date check took 0.011 secs) due to: Output file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl has changed. Output file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\Blend_SCREEN.obj has been removed. Output file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\ColorAdjust.obj has been removed. Compiling native files: [C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\generated-src\jsl-decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\Blend_ADD.hlsl, ... very long line cut..., C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\generated-src\jsl-decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\SepiaTone.hlsl] Starting process 'command 'C:/Tools/DxSDK/utilities/bin/x86/fxc.exe''. ..... skipped ... Successfully started process 'command 'C:/Tools/DxSDK/utilities/bin/x86/fxc.exe'' compilation succeeded; see C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\Blend_BLUE.obj If I then do gradle clean gradle then the log looks like this: :graphics:compileDecoraHLSLShaders (Thread[main,5,main]) started. :graphics:compileDecoraHLSLShaders Executing task ':graphics:compileDecoraHLSLShaders' (up-to-date check took 0.007 secs) due to: Output file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl has changed. Output file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\Blend_SCREEN.obj has been removed. Output file C:\Vadim\jfx-8.0-graphics-clean\rt\modules\graphics\build\hlsl\Decora\com\sun\scenario\effect\impl\hw\d3d\hlsl\ColorAdjust.obj has been removed. Compiling native files: [] :graphics:compileDecoraHLSLShaders (Thread[main,5,main]) completed. Took 0.05 secs. Other than that logs look very similar.
22-11-2013
I can confirm this same error with an OpenJFX build. Without the patch it works fine. I can't think of anything in the patch that should behave differently on an open versus a closed build, but apparently there is.
22-11-2013
Btw, I haven't tried an OpenJFX build (just a closed build), so I will try that next.
22-11-2013
I just ran "hg purge --all" on my repo (equivalent to cloning a fresh repo) and did a build. It still works fine for me. I made changes to native files, ran "gradle" again, and it builds the native files with the changes. If it doesn't work for Anthony and Vadim then it can't be pushed until we know why, and until it works for them.
22-11-2013
Yes, that was my suspicious when seeing the error.
22-11-2013
I just did clean OpenJFX build with the patch and there are the same error as in RT-31640, no com/sun/prism/d3d/hlsl folder and no com/sun/scenario/effect/impl/hw/d3d/hlsl in the jfxrt.jar They are compiled, but not copied. Without the patch they copied into the jar.
22-11-2013
Thanks, Chien. It still looks suspicious since you've observed the exception, too, even though it's gone now. I'm currently cloning a fresh clean repo and will try with that.
22-11-2013
I got the com.sun.prism.d3d.D3DResourceFactory.createStockShader() error during my initial testing but this problem went off after I did a complete clean and build. I just retest the build and run your suggested DragDropWithControls program. It runs fine for me with instrumented printout to prove it did pick up my latest change to the native code.
22-11-2013
Yes, I did. I just re-verified this with a clean build and it failed for me with the same exception again. Could anyone else try this on Windows please?
22-11-2013
I don't see this failure on my Windows build. Did you do an initial clean build after first applying the patch?
22-11-2013
The fix doesn't seem to work for Glass. I've had a build. I do the following: $ gradle cleanNative clean $ rm -rf build .gradle buildSrc/.gradle $ patch -p 1 < rt.patch <----------- Felipe's patch $ gradle At this point I get a clean build with Felipe's patch applied. Now: $ gradle This completes in 40 seconds as no files have been changed. So far so good. Then: $ touch ./modules/graphics/src/main/native-glass/win/* $ gradle And this also completes in 40 seconds w/o rebuilding Glass. Am I doing something wrong or the fix doesn't actually fix anything?
22-11-2013
This could be an issue with my last build. I retried with a clean build and the patch work really well for both d3d and es2 native code update build. Thanks!
22-11-2013
This patch isn't ready. A partial build on a d3d native change will fail with a long stack trace and the native clean target for d3d is broken too.
22-11-2013
Nice work! I think the patch is fine as it. It seems the least-intrusive solution and fixes the problem for me. Chien might want to test it, if he can do it quickly, but this is a "GO" from me.
22-11-2013
New fix http://cr.openjdk.java.net/~fheidric/RT31360/webrev/ Based on Richard's patch. The main change is that allFiles is created up front and later it call allFiles.clear() instead of re-creating the list. Questions: 1) I find it unnecessary to have both sourceRoots and allFiles, we really need one. Should I change that ? 2) Did we ever tried to use http://www.gradle.org/docs/current/userguide/nativeBinaries.html instead of defining our own native tasks ? 3) Did we ever tried gradle incremental tasks support http://www.gradle.org/docs/current/userguide/custom_tasks.html#incremental_tasks instead of implementing our own solution (maybe not available at the we started, gradle 1.4) ? Note: (2) and (3) are of question for 8, but I would like to know the answer for future reference. Thank you.
22-11-2013
CR-FX8GFX-64-patch-0.txt is Richard's patch as is. A problem with it is if source() is never called the allFiles is never initialized and it fails on compile(). That is the case for all CompileResourceTask, but glass (at least til RT-27943 is fixed). I'm pretty sure that was the problem Chien ran into when he tried the patch.
22-11-2013
I confirm that reverting the patch restores the correct behavior. Please try running any toy (I used DragAndDropWithControls) and see if it runs OK.
22-11-2013
Interesting. I'll give it a try. However, I've just run into com.sun.prism.d3d.D3DResourceFactory.createStockShader (RT-31640) running a toy in a repo with Felipe's patch applied. I'll try a new clean build now w/o any patches...
22-11-2013
You need to actually change the contents of the file in order for gradle to rebuild it (this is true for Java files as well). gradle keeps a checksum and won't recompile a file just because the time stamp changes.
22-11-2013
Note, Richard make a fix available but that broke decora, I have not had the time to see what is happen. Please give me to the end of the week, maybe this is easy...
21-11-2013
Steve, the workaround is already available and it is pretty much what you asked: gradle cleanNative sdk (which should be used when working on native code). By get rid do you mean defer or fix ?
21-11-2013
We want to get rid of this one quick for ZBB!
21-11-2013
Felipe, if you can't actually fix this, please add a flag whose default is true that considers natives to be always out of date. Smart developers can set it to false and not compile natives.
21-11-2013
If you want the files copied to the right place then: gradle cleanNative sdk
23-10-2013
Note I have also released a improved work around ;-) For example, rebuild only font: gradle cleanNativeFont gradle nativeFont rebuild all natives gradle cleanNative gradle native NOTE: this will not copy the new libraries the final location, I personally set java.library.path to modules/graphics/build/libs/font/win/. I guess if you are on Netbeans that is a bit my painful...
28-08-2013
Agree. However, the severity of this issue is really high.
28-08-2013
There are workarounds so technically this cannot be a blocker
28-08-2013
This is a vitally important feature of the build system. Please fix it asap.
28-08-2013
my new and improved workaround $ rm -fr modules/graphics/build/libs/font/win/ $ rm -rf modules/graphics/build/native/font/win/ $ gradle nativeFont make sure your ld.library.path has modules/graphics/build/libs/font/win/ first. or copy the lib the artifacts cp modules/graphics/build/libs/font/win/javafx_font.dll ../artifacts/sdk/rt/bin/
24-07-2013
so basically we are back stuck using 'gradle clean sdk' everytime ?
17-07-2013
Note that Richard will look into a fix that doesn't break the hlsl compilation.
16-07-2013
I had to backout the changeset that fixed this bug since it introduced RT-31640, a critical regression preventing anything from running on Windows platforms.
16-07-2013
Tested on Windows with Glass native code. Works like a charm. Thanks!
15-07-2013
works for me (mac)
11-07-2013
I believe this is now fixed. I tested on Mac and Windows and it looked like it was working, unless I pulled a Billy! Changeset: 142f5a3007a6413ee1d3ca81d67cfb630506d641 [142f5a3007a6] Parents: 4258 Author: rbair Date: July 10, 2013 10:02:06 PM PDT Labels: tip RT-31360: Gradle build system doesn't do partial build if native code is changed
11-07-2013
I believe I have a fix for this. The problem is that I was not properly telling gradle what files it should pay attention to in order to do its partial build support
01-07-2013
Hi Richard, give it a try: 1) edit jfx/rt/modules/graphics/src/main/native-font/coretext.c 2) $gradle nativeFont At this point I expect a new libjavafx-font.dylib to be either at jfx/rt/build/mac-sdk/rt/lib or jfx/artifacts/sdk/rt/lib but the timestamp is not changed, the library was not build. You can also try editing jfx/rt/modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTFontStrike.java, but you will get the same result.
29-06-2013
So you are seeing the native file built, but the lib is not being built?
29-06-2013
Yes, the build time after doing grable clean. Here is the time taken on my laptop: :sdkWin :sdkArtifactsWin :sdk BUILD SUCCESSFUL Total time: 4 mins 24.376 secs
29-06-2013
Btw, on my laptop (Core i5 with SSD) a build from clean takes: Total time: 3 mins 52.068 secs
29-06-2013
I think he means an sdk build following a clean.
29-06-2013
really? clean is reasonably fast on my 2007 MBP.
28-06-2013
Yes, I need to do a "gradle clean" followed by "gradle" to have the native change rebuild. Luckily, a clean build now only takes slightly less than 5 min. on my laptop. :-)
28-06-2013
I think I having this same problem I tried $gradle nativeFont It was successful but the library was not built (I had changes to coretext.c) I tried deleting the files in build/mac-sdk -- didn't help I tried editing a java file (in graphics, CTFontFile.java) -- didn't help (it built the .class, but not the library it seems) I tried a full build ($gradle) -- didn't help I tried a clean build followed but full build -- now it worked
28-06-2013

Relates :	JDK-8090157 - JNI headers should be re-generated when a .java file changes
Relates :	JDK-8092360 - Only modified native files should be re-compiled
Relates :	JDK-8119317 - Exeception throws on any JavaFX program on the Windows (d3d) platform