aboutsummaryrefslogtreecommitdiff
path: root/test cases/python/9 extmodule limited api/limited.c
diff options
context:
space:
mode:
authorMis012 <Michael.Srba@seznam.cz>2024-02-15 20:21:56 +0100
committerJussi Pakkanen <jpakkane@gmail.com>2024-06-10 01:48:53 +0300
commit9694f9fefeee6ac7c729c3a520c43902e6fb76f1 (patch)
tree2d3b3a20b1fc1c2b0bceeaa694e8e2d6f4aee4ee /test cases/python/9 extmodule limited api/limited.c
parent374fa7f0da278d46a4c3adb587f4b43089f5d7db (diff)
downloadmeson-9694f9fefeee6ac7c729c3a520c43902e6fb76f1.zip
meson-9694f9fefeee6ac7c729c3a520c43902e6fb76f1.tar.gz
meson-9694f9fefeee6ac7c729c3a520c43902e6fb76f1.tar.bz2
java: use single javac invocation per jar
Instead of invoking javac for every .java file, pass all of the sources for a jar target to a single javac invocation. This massively improves first compilation time and doesn't meaningfully affect incremental builds (it can even be faster in some cases). The old approach also had issues where files would not always get recompiled even though they should, necessitating a clean rebuild in order to see changes reflected in the build output. Multiple invocations seem to only make sense if: - issues with files not getting flagged for rebuild are investigated and fixed - something like the javaserver buildtool from openjdk sources is used instead of directly spawning javac processes - the amount of java files per jar is so large that it is faster to compile several files one by one than to compile all the files at once (batching may still make sense to get a reasonable balance)
Diffstat (limited to 'test cases/python/9 extmodule limited api/limited.c')
0 files changed, 0 insertions, 0 deletions