possible to use dependsOn with compile (0.10.0)

[Keith Irwin]

I've got a build.scala in ~/project with:

  val sampleTask = TaskKey[Unit]("sample")

and in build.sbt

  sampleTask := {

    println("SAMPLE")

  }

  compile <<= compile.dependsOn(sampleTask)

and I get the following error when sbt tries to compile the build.sbt file:

  sbt.Init$Uninitialized: Reference to uninitialized setting {file:/Users/keith/Desktop/my-project/}my-project/*:compile from {file:/Users/keith/Desktop/my-project/}my-project/*:compile

I can (as per the docs) make my own custom tasks depend on each other just fine.

Am I missing something?

Keith

[Keith Irwin]

On Sat, Jun 4, 2011 at 11:54 AM, Keith Irwin <keith...@gmail.com> wrote:

Was thinking that maybe scoping was my problem:

I've got a build.scala in ~/project with:

  val sampleTask = TaskKey[Unit]("sample")

I've also tried it add "in Compile" to the above. No go.

 

and in build.sbt

  sampleTask := {

    println("SAMPLE")

  }

As well as "sampleTask.in(Compile)", also no go.

I think a nice example in the Full and/or Quick examples with tasks that interact with the default ones would be nice. For instance, there aren't any examples of tasks inside a Full build definition. Is that where I need to do to change dependencies of default tasks?

I've got this case:

 * coffeescripts that need to be transformed into javascript

 * scalate templates that need to be precompiled

 * good old scala code

I can make individual tasks for the first two which work fine (after a fashion, given no plugins at this point). What I can't do is hook them into any of the existing default tasks. For instance, depending on what I'm working on, I can "sbt coffee" or "sbt templates" or "sbt compile", but when I do "sbt run", I'd like to have the run task depend on coffee and templates.

The value of this to me is that I can use standard sbt commands, rather than making up my own.

sbt 0.7.x was pretty clear about how to engineer all this stuff, but the task stuff for 0.10.0 seems unclear, or at least the errors do. Hopefully, I'm just missing some core metaphor that'll put it all together for me.

Keith

ps. I was able to use clean: clean <<= clean.dependsOn(coffeeClean) and so on.

 

  compile <<= compile.dependsOn(sampleTask)

and I get the following error when sbt tries to compile the build.sbt file:

  sbt.Init$Uninitialized: Reference to uninitialized setting {file:/Users/keith/Desktop/my-project/}my-project/*:compile from {file:/Users/keith/Desktop/my-project/}my-project/*:compile

I can (as per the docs) make my own custom tasks depend on each other just fine.

Am I missing something?

Keith

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/QnNHdW1fVzc2UklK.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Mark Harrah]

Hi Keith,

On 6/4/11, Keith Irwin <keith...@gmail.com> wrote:
> I've got a build.scala in ~/project with:
>
> val sampleTask = TaskKey[Unit]("sample")
>
> and in build.sbt
>
> sampleTask := {
> println("SAMPLE")
> }
>
> compile <<= compile.dependsOn(sampleTask)
>
> and I get the following error when sbt tries to compile the build.sbt file:
>
> sbt.Init$Uninitialized: Reference to uninitialized setting
> {file:/Users/keith/Desktop/my-project/}my-project/*:compile from
> {file:/Users/keith/Desktop/my-project/}my-project/*:compile

The immediate cause of this error is that there is no *:compile test,
only test:compile and compile:compile. It is similar to saying

override def globalCompile =
super.globalCompile.dependsOn(sampleTask)

but where globalCompile isn't defined yet. You want something like:

compile in Compile <<=
(compile in Compile).dependsOn(sampleTask)

However, 'dependsOn' should be rarely used because there are better
ways to hook in. For example, there is are new source generation
hooks. In general, tasks produce a value that gives the useful
information that should be propagated to dependent tasks. This means
you usually want to 'map' a task.

It looks like you gave some more details on what you are doing in your
follow-up email, so I will try to give some more specific help when I
get the time and I'll document the source generation hooks. This is
important enough that you can open a bug to ensure it gets documented
and doesn't get lost.

Thanks,
Mark

> I can (as per the docs) make my own custom tasks depend on each other just
> fine.
>
> Am I missing something?
>
> Keith
>

[Keith Irwin]

Yes, I started looking in to the sourceGenerators stuff (by finding Keys.scala) but couldn't quite figure out what to do with it. I was hoping xsbt itself would use xsbt.

And, yes, I hear you about integrating my needs into the existing infrastructure without altering the main tasks. The plugins for the old SBT are a good example of that. I have trouble finding the discoverability of the tool, but then I've only spent a few hours.

I'll create an issue asking for an example of the sourceGeneration stuff. I think plugin writers could really use that help.

Keith

[Mark Harrah]

On Sat, 4 Jun 2011 14:49:38 -0700
Keith Irwin <keith...@gmail.com> wrote:

> ps. I was able to use clean: clean <<= clean.dependsOn(coffeeClean) and so

If you prefer, you can add files to clean to the `cleanFiles` setting. You can explore settings using 'inspect' and looking at the dependencies section.

https://github.com/harrah/xsbt/wiki/Inspecting-Settings

-Mark

[Mark Harrah]

For the benefit of the list, source generation is added as a use case to [1]. If there are specific use cases you would like to see covered there, please either add it yourself or describe the use case and I or someone else who knows how to do it might add it.

-Mark

[1] https://github.com/harrah/xsbt/wiki/Common-Tasks