My thoughts on Phantom

[Andrey Shchekin]

So there are my thoughts:
I think that the build scritps in Boo is the best thing possible
without leaving the .NET and using Rake.
So, I am definitely going to use this, and the more people use, the
better.

Ok, now what I feel can be done to make it a perfect build tool
instead of just great.
I am going to try some of these when I manage to understand git.

1. Target dependency syntax. It does not feel natural writing A, (B,
C) to run B C A.
The problem is that "," feels like an order specifier to me, and using
it for two things here seems confusing.
I am not sure what you can do with macros, but something like
target build < (release, publish):
or
target build do (release, publish) then:
or
target build after (release, publish)
would be better.

2. File inclusion -- I know Rhino DSL supports [import file from
'xyz'], but it compiles the file first, so, for example, variables not
available.
And variables seem very important as an easy way to configure the
build process.
I think [import content from 'xyz'] would be nice, and may be even
possible (by merging two AST trees?).

3. Command-line arguments as a way to pass parameters (by injecting
them into AST tree as globals?).
4. Build-in logging methods/macros corresponding to different log
levels would be great [warn "..."]

Not immediately realistic, but awesome possibilities:
5. I think transparent support for NAnt/MSBuild tasks would be great
-- basically, exposing task as a function and running it without
starting external NAnt process.
This might be hard to do, but is awesome to have, since there are a
lot of tasks already built for these.
6. Finally, msbuild has a really nice support for detecting whether
the target should be run by comparing timestamps of the inputs to the
timestamps of the outputs.
I am really missing this in NAnt, some support for that would be nice.

Last minor (taste) thing, CopyToDir is nice, but could it be
CopyToDirectory just to be consistent with .NET naming?

I will try some of these things myself, probably, and I'll tell if I
produce something useful.

Thanks for reading all of this,
Andrey

[Jeremy Skinner]

Hi Andrey,

Thanks for your feedback.

> 1. Target dependency syntax. It does not feel natural writing A, (B, C)

I agree...it doesn't read very well. I like your suggestion for "target build after (release, publish)". I'll have a play and see if I can get this working.

> I think [import content from 'xyz'] would be nice, and may be even
> possible (by merging two AST trees?).

I like this idea, but I have absoloutely no idea how to do this :-)

> 3. Command-line arguments as a way to pass parameters (by injecting
> them into AST tree as globals?).

This is already supported, but through the environment variable collection rather than as globals (as with Rake). If you call "phantom.exe -a:foo=bar" then you can access this value by using env("foo") from within the script.

> 4. Build-in logging methods/macros corresponding to different log
> levels

Not sure I follow what you mean here...could you elaborate?

> 5. I think transparent support for NAnt/MSBuild tasks would be great

An interesting idea but not sure how feasilble this would be. I'd rather focus on providing Phantom equivalents to the commonly used tasks rather than trying to support a mini nant/msbuild runtime.

> 6. Finally, msbuild has a really nice support for detecting whether
> the target should be run by comparing timestamps of the inputs to the
> timestamps of the outputs.

It's been a long time since I did any work with msbuild directly and I don't recall ever making use of this...do you have a link to more information about this?

> Last minor (taste) thing, CopyToDir is nice, but could it be
> CopyToDirectory just to be consistent with .NET naming?

Probably sensible...if you want to create an issue for this on the issue tracker then I'll get it changed.

Thanks again for the feedback.

Jeremy

[Andrey Shchekin]

Hi Jeremy,

Thanks for the answer,

 

> I think [import content from 'xyz'] would be nice, and may be even
> possible (by merging two AST trees?).

I like this idea, but I have absoloutely no idea how to do this :-)

Ok, I'll try this.

> 3. Command-line arguments as a way to pass parameters (by injecting
> them into AST tree as globals?).

This is already supported, but through the environment variable collection rather than as globals (as with Rake). If you call "phantom.exe -a:foo=bar" then you can access this value by using env("foo") from within the script. 

I think having a function is more reasonable than a global (or not? having a global has a benefit of crashing when it is required but not set. not sure).

But do these environment variables propagate to processes spawned by build process? If yes, then it may lead to undesired side-effects.

> 4. Build-in logging methods/macros corresponding to different log
> levels

Not sure I follow what you mean here...could you elaborate?

I can do "print", but both NAnt and Msbuild has different log levels configurable through command line arguments.

For example, for MSBuild it is q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].

Detailed log can be 2Mb while small log can be just several lines.

So instead of print, I would prefer several commands that are dependent on the log level, like warn "xyz" -- show in all levels except quiet.

I do not yet know what levels should be there, just thinking about it because I wanted to have a lot of logging in my build, but just for debug mode.

 

> 5. I think transparent support for NAnt/MSBuild tasks would be great

An interesting idea but not sure how feasilble this would be. I'd rather focus on providing Phantom equivalents to the commonly used tasks rather than trying to support a mini nant/msbuild runtime. 

Equivalents are good, but there are less common tasks that are still very useful, such as tasks provided by a specific tools/products (MbUnit, etc).

Anyway, I think I'll try this in a fork, then if it would be successful you can decide whether to integrate or not.

 

> 6. Finally, msbuild has a really nice support for detecting whether
> the target should be run by comparing timestamps of the inputs to the
> timestamps of the outputs.

It's been a long time since I did any work with msbuild directly and I don't recall ever making use of this...do you have a link to more information about this?

Sure, when you define target, you can also define Inputs="" and Outputs="". Both are file sets.

If any file in inputs is newer than any file in outputs, or any file in outputs does not exist yet, then target is run.

Otherwise it is not.

This is an easy way to save a lot of time on large builds or builds that run often.

Andrey

[Andrey Shchekin]

Hi Jeremy,
Let's update where we are standing on these points.

1. Target dependency syntax.
I think I'll probably look into this next. I see one possible problem
with 'after', however.
It seems to imply that this task will be immediately run after the
dependencies, which is not true (task will not run unless it is said
to run or some other depends on it).
It is interesting that MSBuild 4 has BeforeTargets and AfterTargets
which explicitly specify when a target should be run (in addition to
normal dependency syntax).
I think right now I prefer something like 'target build requires
(release, publish)'. What do you think?

2. File inclusion
Mostly done, I am noticing some strange issues caused by RhinoDsl
approach to caching, will look into fixing them.

3. Command-line arguments as a way to pass parameters

Current parameter passing method (env()) strikes me as dangerous since
env variables should by the OS rules be passed to the spawned
processes.
I have not experimented with it, but I do not see a benefit of using
environment vars either, except for Rake legacy, which is not well
known to most of .NET devs.
One thing that I am missing with current parameter mechanism is that
it is hard to make a certain parameter required (with validation by
the framework).
On the other hand, parameter may be required only by a certain target,
which makes injecting a global meaningless, since the compilation will
fail even if target is not run.

I do not yet have a complete idea of what is the best solution, but
some kind of parameter requirement specification by the target would
be great.
I am trying to find a solution that will not overcomplicate things
while being similar to NAnt <property> in flexibility.

4. Build-in logging methods/macros corresponding to different log
levels

Ok, this basically comes to the need of a configurable multilevel
logger used by tasks through the base task.
Logger is generally a good thing because it allows, for example, for
XML build reports/Colored console reports/etc.
I would say that if a logger is implemented, a nice thing to do would
be to make
NAnt-Phantom logger adapter (to use any existing loggers written for
NAnt)
and
Phantom-NAnt logger adapter (for 'import tasks from', so the task
logging could be transparent within Phantom logging system).

I understand that it is a lot of work. I'll look into it if I have
some free time.

5. I think transparent support for NAnt/MSBuild tasks

Done for NAnt, not hard to do for MSBuild, will look into it when time
allows.

6. Really nice support for detecting whether the target should be run

by comparing timestamps of the inputs to the timestamps of the outputs

Not sure about that one, needs more thought on my part.

—
Andrey

On Dec 13, 3:47 pm, Andrey Shchekin <ashm...@gmail.com> wrote:
> Hi Jeremy,
> Thanks for the answer,
>
> > > I think [import content from 'xyz'] would be nice, and may be even
> > > possible (by merging two AST trees?).
>
> > I like this idea, but I have absoloutely no idea how to do this :-)
>
> Ok, I'll try this.
>
> > 3. Command-line arguments as a way to pass parameters (by injecting
> > > them into AST tree as globals?).
>
> > This is already supported, but through the environment variable collection
> > rather than as globals (as with Rake). If you call "phantom.exe -a:foo=bar"
> > then you can access this value by using env("foo") from within the script.
>
> I think having a function is more reasonable than a global (or not? having a
> global has a benefit of crashing when it is required but not set. not sure).
> But do these environment variables propagate to processes spawned by build
> process? If yes, then it may lead to undesired side-effects.
>
> > 4. Build-in logging methods/macros corresponding to different log
> > > levels
>
> > Not sure I follow what you mean here...could you elaborate?
>
> I can do "print", but both NAnt and Msbuild has different log levels
> configurable through command line arguments.

> For example, for MSBuild it is *q[uiet]*, *m[inimal]*, *n[ormal]*, *
> d[etailed]*, and *diag[nostic].*

[Jeremy Skinner]

> I think right now I prefer something like 'target build requires
> (release, publish)'. What do you think?

Sounds good - I like 'requires'.

> 3. Command-line arguments as a way to pass parameters

The thing I like about using environment variables is that it is very simple, but if you come up with an alternative then I'd like to see it.

> 4. Build-in logging methods/macros corresponding to different log
> levels

I agree this would be useful - I like the idea of the nant<->phantom adapter.

Thanks again for the work you're putting into this.

Jeremy