Greetings, I'm working on an experiment for building java using the tup system. The goal is to combine tup's strengths (in quickly executing the "minimum-but-correct build steps") with java's strengths (specifying dependencies in-file, unitary readability, etc) at the cost of a few java language paradigms (no wildcard imports, no circular dependencies, etc).
I have reviewed previous efforts and strategies in building java projects, but find the all a bit kludgy and vastly less efficient than tup's design goals. I have a good idea of how I could accomplish the desired effect if I could specify a different ".tup" directory or "Tupfile" name on the command line (a gross oversimplification, I know). NB: I am just typing this out to give an idea of the desired effect:... it may not have the right syntax, wildcards appear where the generator may just enumerate files, and the files surly do not line up. $ cat Tupfile.phase1 : src/main/java/package/A.java |> list-java-references.sh %f |> target/tup1/%B.refs : src/main/java/package/B.java |> list-java-references.sh %f |> target/tup1/%B.refs : src/main/java/package/C.java |> list-java-references.sh %f |> target/tup1/%B.refs : target/tup1/*.refs |> combine-refs-into-Tupfile.sh %f -o %o |> Tupfile.phase2 $ cat Tupfile.phase2 : src/main/java/package/A.java |> javac-one-file.sh %f %o |> target/tup2/%f.class : src/main/java/package/B.java | target/tup2/package/A.class |> javac-one-file.sh %f %o |> target/tup2/%f.class : src/main/java/package/C.java | target/tup2/package/B.class |> javac-one-file.sh %f %o |> target/tup2/%f.class : target/tup2/*.class |> jar cf -o %o %f |> final-product.jar $ cat build.sh find . -name '*.java' | generate-phase1.sh > Tupfile.phase1 tup -f Tupfile.phase1 # i.e. > Tupfile.phase2 tup -f Tupfile.phase2 Ideally: (1) adding or removing *.java files does not require modifying the build scripts, (2) changing the dependencies within the java file automatically propagate to the build system, and (3) modifying a single 'java' file results in only that file being compiled. In particular, I think that tup is a good fit for doing either stage (efficiently maintaining the "*.ref" files or efficiently maintaining the "*.class" files), but I can find no easy or obvious way to glue the two stages together. The limitation seems to be best described in the error message: "Your build configuration must be comprised of files you wrote yourself." At the moment I think I can already cobble something like this together with some kludgy directories (to separate the .tup domains), Makefiles (to glue the tup's together), and rsyncs (to carry-over the effect of modifying a file)... and that it would still be far faster than the equivalent incremental maven build, but I thought that it would be better if I asked beforehand: (1) is there any planned support for (or how theoretically possible would it be to) use a separate Tupfile or '.tup' directory for such multi-phased build systems, (2) is there any planned support for (or how possible would it be to) allow a rule-generating script to read generated files as input, (3) am I missing something that should be obvious? Any help would be appreciated! -- Robert Hailey -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
