Given a Groovy source can contain any number of classes with any names, the detection that ABC depends on a given source DEF is going to be rather at the difficult side.
The only solution I can see is to build all the sources at start and use appropriate ASTTs to create a complete map source <-> classes. This map then (a) could be used to decide which sources to mark dirty and send them to the compiler upon a rebuild (b) could be just as well used to find the source which generates a given class, referred from another one (c) would, of course, have to be updated whenever a source changes and thus could refer/generate different classes than before. Perhaps ther's a better solution which I am overlooking, of course. All the best, OC > On 10. 6. 2025, at 15:15, Saravanan Palanichamy <chava...@gmail.com> wrote: > > Hi Jochen > > Thank you for the explanation. I am not trying to do this with a build system > like gradle or make. I am hosting the Groovy Compiler in a Java CLI and I > have my own customizations. This is my setup > > A Java CLI that bundles the Groovy Compiler and takes command like options to > feed to CompilerConfiguration > I use the CompilationUnit to add all my sources and compile in one shot > My source code is split across multiple libraries. I start with a code base > in package A, that will include package B and C, each of which is a separate > folder. So in a sense I am trying to compile all packages together in one go. > What I want to do > I know a file ABC.java contains a function of interest > I want to compile just that class ABC, even though I have the complete code > closure of everything > As I compile ABC, I want to detect that it depends on DEF.java and I want to > give the compiler DEF. As it compiles DEF, it may pull in XYZ.java, I want to > hand that over. And so on > The goal is to produce bytecode only for ABC and all its dependencies. Some > things I thought of > > Add ABC.java as the only source unit. Then I override resolve visitor, to > detect all resolve attempts. I now know what other classes need to be > resolved, so I try to add new files to the compilation units. The code looks > like it should go back to initialization phase. Now when I see other classes > that I added, I can repeat this process recursively. I am not sure how > feasible this is given the amount of looping back and forth > Your comment about allowing groovy to find the script file was interesting. > So run GroovyC on one file and let the compile find all dependencies as > scripts. This looks like exactly what I want to do in 1. but all my files are > named .java so I am not sure groovy will find them > Which approach do you think I should try? > > regards > Saravanan > > > On Mon, Jun 9, 2025 at 11:28 AM Jochen Theodorou <blackd...@gmx.org > <mailto:blackd...@gmx.org>> wrote: >> On 09.06.25 18:01, Saravanan Palanichamy wrote: >> > Thank you Jochen for your reply >> > >> > some followup >> > >> > * My source files may be in different locations (I want to say here's >> > three different source directories, they form the source closure. >> > But compile only foo.groovy and let the compiler decide what other >> > files in what locations need to be pulled up for the compile). I saw >> > that groovyc is backed by FileSystemCompiler.java and it is doing >> > the same thing I am doing I think (it adds all source files passed >> > in the command line args to the compile unit). What's the way to >> > pass in only foo.groovy but then say here are other source >> > units/files one of which is bar.groovy, just use the ones you need >> > and leave out the others >> >> I think that case is not well supported right now. What you can try is >> giving groovyc a classpath and put each source path in there, then just >> do the compilation with the single file. The compiler should detect the >> source files in the class path >> >> well.. used to... we had no tests in that direction so maybe this >> mechanism does no longer work. We also used to have sourcepath. But >> that would have been for a single directory, you need multiple and well, >> it got deprecated anyway >> >> > If it helps, >> > >> > * I assume every file will only have one class defined (these are java >> > files that are being compiled with the Groovy compiler, so java >> > limitations will help) >> > * I can also do multi pass compiles, time to compile is not a limitation >> >> >> If you want to make this with "make" you could write a make file and >> make tells you what sources changed (based on the class files) and then >> you could just pass the compiles class files on the classpath and the >> changed source files to the compiler. Of course make is kind of archaic. >> >> But you could consider a build system >> >> bye Jochen >>
