Jochen, > On 15. 1. 2024, at 10:35, Jochen Theodorou <blackd...@gmx.org> wrote: > If the goal is to give Groovyc a source file and let it compile that, > but write only certain files... well that is something that could be > worked out.
Well I don't know. Theoretically, it would be nice if the compiler wrote only those .classes, which did change from the previous compilation. I might be overlooking something of importance, but I fear that would be pretty difficult, at the verge of impossible. I guess the solution might be found somewhere nearby creating some hash of the last generated code, stored in .class, checking when building and not re-writing the .class if unchanged... am not sure whether feasible at all. > This is not really incremental compilation like we may know > it from eclipse-java though. I've tried to use the Eclipse thing and it was terrible enough (not just due to unreliable incremental build; a plethora of other problems, GUI ugly as hell, contra-intuitive and completely non-ergonomic, slow and crashing pretty often) that I spent a non-trivial time writing my own scripts and even an external EOF model editor to be able to use Xcode to build my WebObjects/Groovy applications :) Anyway I would be contented with a build system which - never tries to re-compile sources which did not change after the previous build (this works with my scripts all right) - reliably re-builds all the classes generated by a source changed after the previous build (this works with my scripts all right) - reliably deletes classes which were created by the previous build, but do not exist anymore with the current one (and this, alas, my scripts do not support properly yet). I understand Eclipse and other Java-related IDEs do this completely wrong, for they naïvely assume an XXX.source always generates just XXX.class. I might be wrong of course — for years I happily use Xcode plus my scripts and haven't touched those other IDEs by a ten-foot pole; perhaps they improved meantime :) Thanks and all the best, OC > On 14.01.24 21:43, OCsite wrote: >> MG, >> >> I might be wrong (haven't checked for a long long time and at least a >> couple of major Groovy versions), but I believe groovyc always simply >> re-creates all the .class files which result from a source compiled >> (could be a number of them: aside of the closure classes, groovyc — very >> reasonably unlike the Java disaster — supports any number of >> /class/ definitions in one source, and can generate one more as a script >> if the source happens to have statements outside all classes). >> >> (And yes, if your build system supports the incremental build, it can be >> a royal PITA. My scripts — so that I can build directly from Xcode, I >> wrote a set of my own ones — do support incremental and it doesn't work >> quite reliably due to this very problem. I considered to make a special >> support which would internally pair the source with all the classes >> generated from it, allowing the scripts later to check timestamps and >> auto-delete extra classes which are not needed anymore, yadda yadda, >> but, alas, so far I haven't got to implementing it properly — ars longa, >> vita brevis :/ ) >> >> All the best, >> OC >> >>> On 14. 1. 2024, at 20:02, MG <mg...@arscreat.com> wrote: >>> >>> Hi Jochen, >>> >>> 1. we build using IntelliJ, and this has occurred independent of the >>> IntelliJ version for years. >>> 1. (It is now that I work more from home that this becomes more >>> of a nuiscance, due to much slower upload speed to the server.) >>> 2. Does "Groovyc compiles what you give it to compile" hold true in >>> this case ? >>> 1. Closures are compiled to classes, but they do not exist as >>> such in the code, so how would IntelliJ tell Groovyc to >>> compile (or not compile) the closures in a Groovy source file... ? >>> 2. Based on this I always assumed it is Groovyc who decides to >>> recreate all those auto-generated closure classes... (?) >>> >>> Cheers, >>> mg >>> >>> >>> On 14/01/2024 14:04, Jochen Theodorou wrote: >>>> On 12.01.24 18:50, MG wrote: >>>>> Hi guys, >>>>> >>>>> is there a way to get Groovy not to nedlessly recreate closure class >>>>> files during a build which would otherwise just change one or two >>>>> non-closure class files ? >>>>> The recreation of large numbers of closure class files seems to be >>>>> triggered randomly at certain points, and having to continuously >>>>> rsync-upload these files to the server after small code changes becomes >>>>> a factor in turnaround time... >>>> >>>> I think we need a bit more detail. Groovyc compiles what you give it to >>>> compile. If something is deciding one time to compile a set A and >>>> sometimes a set B, then it is because the part controlling Groovyc >>>> decided to do that. >>>> >>>> so what is controlling Groovyc in your case? Gradle, Maven, Intellij..? >>>> >>>> bye Jochen >>>> >>> >> >
