search

arrdem / katamari

Roll up all your software into artifacts!
67 stars 4 forks source link

Generic compile #5

Closed arrdem closed 5 years ago

arrdem commented 5 years ago

Right now, Katamari has two pseudo compile tasks baked in - uberjar and classpath. Neither of these tasks is particularly well defined. uberjar for instance doesn't even check that it's been given a jar target to uberjar. The classpath task would be outright wrong on a java-library target, as there is currently no javac task.

All of this is symptomatic of Katamari's present lack of what it claims to be its flagship feature - support for recursively and correctly "building" (whatever that may mean) depended upon targets in topological sort order as they are needed.

The main challenges here are around choosing an introspectable / traceable build target API and implementing extension points in keeping with the current extension pattern by which user defined build target types can participate in dependency enumeration, freshness checks and "build".

See build systems ala carte for some material here. The minimum API requirements are probably to, given a target, enumerate its dependencies, compute a unique ID for it based on config and inputs, check "freshness", and execute the "build". Mokhov, Mitchell and Jones give a very thorough treatment to this.

The first versions of Katamari aim to provide content addressed (cloud capable), static dependencies and topological build planning. Wrinkles may be introduced to this with profiles and profile application rules, as profiles impact both the dependency graph and the depended nodes as well (eg. adding paths).

arrdem commented 5 years ago

Somewhat fixed by #12 - still need incremental rebuilds capabilities.