Hi, sorry for the late reply! Boot pretty much takes care of that part for
you, as long as you follow a few basic rules (I will be adding a “how to be
a good citizen of the boot-o-sphere” section to the wiki on github soon):
1.
Tasks don’t fish around in the filesystem directly to find things to
compile or otherwise operate on. Instead, tasks use functions in
boot.core that return immutable sets of java.io.File objects from
boot-managed temp directories. These functions present a sort of overlay
filesystem with files in anonymous temporary directories. This allows tasks
to be completely decoupled from the filesystem layout. Additionally, this
makes it possible for boot to shuffle files around and use hardlinks and
such to craft the classpath and the build fileset in different ways during
the build cycle. In this way boot can emulate immutability and lexical and
dynamic scope for things on the filesystem.
2.
Tasks don’t create files in the filesystem directly. Instead, tasks use
functions in boot.core that create various flavors of anonymous,
boot-managed temp directories (the ones mentioned in item 1, in fact). An
important concept in boot is that the output of any task is part of the
input for the next task in the pipeline. This is the property that supports
the amazing composition of tasks that is possible with boot, without
needing to generate miles of boilerplate configuration.
3.
The boot-managed temp directory lifespan is one build session only. This
means one JVM, basically. The temp directories are stored in the .boot
directory in the project root. The next time you run boot it cleans out any
old temp dirs in there (they are not cleaned up on exit because you may
want to look in them if something goes wrong with the build; stack traces
could be referencing source files in these temp dirs).
4.
The only directories that boot knows about that are not temp dirs it
created are the ones you specify in the build.boot file via set-env!
(i.e. the :src-paths, :rsc-paths, and :tgt-path keys). The source and
resource paths are not molested by boot in any way (no files in there are
ever deleted, moved, modified etc.). The target directory, on the other
hand, is completely owned by boot—boot will overwrite files or delete them
in there as it sees fit. Boot ensures that the target directory always
contains only those files the build process emits for that specific run,
and doesn’t allow any stale files to hang out in there.
What this all means is that there is something of a tradeoff: boot never
persists files that could become stale, so there is no need for a clean
task, but on the other hand some things then need to be rebuilt instead of
just hanging out in the target dir. We think this is an okay tradeoff
because boot’s composition capabilities make it really easy to
incrementally run any build process at all using the built-in watch task.
In return you get 100% deterministic builds.
We’ll be talking about the details of the whole temporary filesystem
machinery soon. Have fun playing with boot!
--
Micha Niskin
On Mon, Nov 3, 2014 at 5:45 PM, Laurent PETIT <laurent.pe...@gmail.com>
wrote:
> And more seriously, I remember reading that you put an emphasis on
> removing the need to use a clean task.
> If I'm right, then I'd be interested in knowing how one is encouraged /
> helped to pursue this good property in its own tasks ?
>
> Le lundi 3 novembre 2014, Laurent PETIT <laurent.pe...@gmail.com> a
> écrit :
>
> Tongue in cheek question: if Leiningen were the maven of clojure, would
>> you say boot2 is gradle ? :-)
>>
>> Le lundi 3 novembre 2014, Micha Niskin <micha.nis...@gmail.com> a écrit :
>>
>>> Hi!
>>>
>>> Boot (http://github.com/boot-clj/boot) is a build tool for Clojure.
>>> We've pulled together lessons learned from a year or so using boot v1 in
>>> production and are now getting ready to release v2. To show what boot can
>>> do we present a very streamlined and awesome boot-based ClojureScript
>>> development workflow (
>>> http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/).
>>>
>>> Try it out, maybe you'll like it! We're hoping to get some feedback
>>> before committing to a stable release, so please if you have any comments
>>> or questions we'd be happy to hear them. Have fun!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Laurent Petit
>>
>>
>
> --
> Laurent Petit
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/YAckwMSfZkY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
