Am 15.01.24 um 20:24 schrieb o...@ocs.cz:
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.
Assume the following Java-like
import static Foo.bar
class BarExec {
public Runable getExec() {
return new Runable() {
public void run(){ bar() }
}}}}
So basically this wraps a call around Foo.bar, in way you would not do
it anymore these days, but this is just for illustration. So assume my
change now is replacing the import and import Foo.bar2 instead of
Foo.bar. Because the method is called in the anonymous class in getExec
the minimum we need to do is recompile BarExec$1. BarExec does not need
recompilation, even though the code we changed is not even directly in
the inner class. That kind of problem makes it really difficult to do
any kind of partial compilation
But the idea with a hash (where we compile the whole file) sounds
possible to me.
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
:)
yeah, Eclipse has its weaknesses
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).
to know what files we would create we would have to do a complete
compilation process except the actual writing of files. Under the
assumption of a class Foo will produce a number of class files
Foo($.+)*.class we could then in theory identify which files for Foo are
then surplus. But if you for example deleted Bar.groovy, then we do not
have a Bar.groovy to find out that we do not need Bar.class and
Bar$1.class anymore. For this we would have to compile all source files,
though we would not have to create the class files of course.
Now what do you understand under re-compile? process the source like in
a normal compilation and write out the result, or does it not matter if
the result is written out? If the later does not matter, then
determining the list of unused top-level classes conflicts with the idea
of re-compiling only files that did not change. This is also because in
Groovy a source file can contain any number of top level classes, it
does not even have to contain a class that is similar to the name of the
file.
But of course if you say you want the fixed relationship of one file
containing one class and its inner classes, then this is actually
solvable. For example if there is a bar.class but not bar.groovy we can
delete bar.class. Or if there is bar.class bar$1.class and bar$2.class
and if bar was changed, then any bar class file with a time from before
the last compilation can be deleted.
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 :)
IDEs usually know that there can be more. At least inner classes for the
Java case. Well... they all got even more memory hungry mostly.
Sometimes it is interesting to work with something like vscode for
example. It makes a more lean impression... but in the end it is similar
bad in terms of memory consumption once you start adding plugins. If you
are happy with xcode, stay with xcode ;)
bye Jochen
bye Jochen
