ReFake: an incremental build logic DSL #497
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My effort at creating an incremental build DSL on top of FAKE. For several reasons, as explained in the commit message, I did this by creating a new type of build 'target' that stores more information about the target and its dependencies. The implementation is as simple as possible; there are no lookups of target names to objects happening in the background. The build script writer directly creates target objects using the helper functions, and arranges them into a dependency network at the same time. They then run the topmost target in the network to lazily build whatever needs to be built.
This also allows a pretty elegant way of setting up multiple build configurations in the same script using what I call 'virtual targets'. A simple example:
Because the
releaseConfig
target is a dependency of thereleaseBuild
target, it will always be run beforereleaseBuild
; and will thus set up the release parameters.I'm currently trying to convert the
FakeLib.fsproj
file into a ReFake build script, and am about 80% there. Just ironing out a few referencing issues now.This is a first effort, so I'd welcome feedback.
Relates to issue #235.