A couple of semi-random (coming from the Maven world where failed tests means a broken build) thoughts - not sure what others think:

1. Should the build::BuildPod.test target be included as part of the build::BuildPod.full target?
2. Should pods with broken tests still be published to <FANTOM_HOME>/lib/fan (or the equivalent working repository)?

Martin

I guess I am not one of those super hardcore guys that says you can't even use a pod because it doesn't pass its test suite :-) I often need to do work even if I have partial failures. So I definitely think we should still publish to lib even on test failures.

Whether test should be part of full or not I guess is an interesting question. I would say 90% of the time I always run "build full test", but sometimes I do want to skip tests, and I'd still want an option for that - full does lots of things like include the API docs and build the java, .net, and js natives. But it does not build the docs or run the tests. So it is sort of misnamed if we want to try and come up with other target names.

BTW, the dist target which builds the full distribution I post does require that all tests pass.

So I definitely think we should still publish to lib even on test failures.

Should that choice be an opt-in one rather than an opt-out one? i.e. you choose to use a build with failed tests rather than blowing away a "good" build? (for some value of good - for the sake of discussion: a build which previously passed all tests it had)

... but sometimes I do want to skip tests ...

Just thinking out loud here (and pretty sure it's of minimal value compared to the effort involved) but how about allowing the exclusion of targets from the command line? Something like:

fan build.fan full -test

Which would do the obvious (run everything except the test target). Obviously, if you excluded something critical and it broke ('fan build.fan full -compile') it's your own fault.

From there, it'd be possible to consider a "complete" end-to-end build as the default, and then cut back on what's really needed for your particular development process.

If you're:

not one of those super hardcore guys that says you can't even use a pod because it doesn't pass its test suite :-)

... then no biggy, you can just not run tests and not have them fail. If you want to follow "best practice" (quotes intentional, best is in the eye of the beholder) then you get that OOTB.

I don't think we really need to do anything complicated like test exclusion or the like. I think we just need to define a set of targets and let people decide which targets they want to use. I am open to suggestions for creating new targets or changing the semantics of "full" (as long as we create another target that does what "full" does today). Like most things in software it is just coming up with good names :-)

One thing to keep in mind is that you can't actually run the tests unless the pod is installed for the runtime to run it. We could potentially get into nasty issues like switching repos etc, but that might be best done in an layer above the core distro.

So, the targets currently defined by build::BuildPod we have (functional tasks):

• dumpenv
• clean
• compile(Bool includeFandocAndSrc := false)
• javaNative
• dotnetNative
• js
• doc
• test

As well as the "rollup" tasks:

• compileAll; which calls:
  • compile(false)
  • javaNative
  • dotnetNative
  • js
• full; which calls:
  • clean
  • compile
  • javaNative
  • dotnetNative
  • js

I suggest we need to add something like:

• <TO BE NAMED> which calls:
  • clean
  • compile(true)
  • javaNative
  • dotnetNative
  • js
  • test

I don't know whether dist would be a reasonable name for this (assuming the name clash in buildall.fan isn't a major drama). Something doesn't feel right with using dist for something which doesn't really result in an (obviously) distributable artifact. Perhaps full is a better name for this target and a rename of the current full would be more appropriate?

We are getting ready to integrate js compilation into the normal compile process. And it is mostly useless to build a pod with natives without JVM. And I'm sure clean has much value since building pod is an all or nothing process. So maybe we simplify and just say:

• compile: clean compile of pod with all associated natives
• ???: compile + test
• full: compile + test + doc

Then compile would make a more natural default target (I think we are currently using full in a weird way). Or we could say full is compile+test, and not have a single target that includes doc (you can always pass extra targets on command line)

Definitly, I will think that doc should not be part of any target, keep it simple with compile and full = compile + test.

Doc can be added if needed.

I think (as lbertrand said) doc shouldn't be included in the default build target. So, from top to bottom, I see the process going something like:

• clean
• compile
  • compileFantom
  • compileJs
  • compileJava
  • compileDotnet
• test
• full
  • clean
  • compile
  • test
• dist
  • full
  • doc
  • zip

Renamed from Increasing the visibility of test in builds to Simplify standard build targets

Promoted to ticket #883 and assigned to brian

OK, let's simplify the build targets per @msl proposal:

• clean
• compile: fan+natives
• test
• full: clean+compile+test
• doc

Note sure we should have a "dist" target per pod yet since doc just builds to a local directory and doesn't do anything to package things up for distribution. Although I think once we do our Fan-CPAN we'll end up with some target like that.

What is Fan-CPAN?

I think Brian means the future Fantom library distribution mechanism. Something that fills the roll that CPAN does for Perl and Gems does for Ruby.

Although I think once we do our Fan-CPAN

Shouldn't that be CFAN? :)

Ticket resolved in 1.0.49

The build targets have been simplified as specified above