Wishlist of make like features.

[Peter Nordlund <pe...@lentus.se>]

Hi,

There are a few useful features from make that I miss in ant.
I will just mention them to start a discussion to see if there is any
interest.

* 1.
make -k: Keep going when some targets can't be made.

* 2.
make -n: Dry-run. Don't actually run any commands; just print them.

* 3.
Concerning log output:

I find it a bit difficult to control the amount of output that I
want from ant.

I (personally) most of the time would like to see all commands
excecuted . E.g. for a javac task, I would like to see
the classpath used, is debug on or off, etc.?
I guess that is a bit similar to makes default behaviour.

If I run ant with -verbose, I get far to much information.
All this info may be good when you are debugging your ant code,
but for regular use I think it is too much.

In make, when you put a @ before a command, this command will
not be echoed to stdout.
Maybe a property could be added to the ant tasks, something
like: verboselevel="[0-9]" which could control how much
info this particular task outputs.


When I run ant in the following style:
ant compile > /dev/null.
I think that a build failure should show up on stderr, but as it
is made today, the build failure goes to stdout i.e. to /dev/null.


Best regards,
Peter

Re: Wishlist of make like features.

[Michael McCallum <gh...@xtra.co.nz>]

> > It seems we need a logging level between INFO (what you see when you
> > don't specify a command line switch) and VERBOSE (what you get when
> > you say -verbose). Or the other way around, add an -extraverbose
> > switch and lower the priority of most VERBOSE output to EXTRAVERBOSE.
Why not syslog style crit, error, warn, info, debug.

RE: Wishlist of make like features.

[Conor MacNeill <co...@m64.com>]

> From: petern@peternl.analytikerna.se
> [mailto:petern@peternl.analytikerna.se]On Behalf Of Peter Nordlund
> Sent: Wednesday, 6 September 2000 20:01
> To: ant-dev@jakarta.apache.org
> Subject: Re: Wishlist of make like features.
>
>
> >
> > You mean "[copydir] Copying 2 files to x/y/z" but don't do
> > anything.
>
> Yes that is exactly what I mean.
>

... but that is not really what make does. Make shows you the command line
it will execute, not the output of the commands themselves. Similarly if
this feature were to be added to ant, it should be at the core level and not
the task level. The only reasonable output then would be to show the task
that would have been executed, its attributes and perhaps its nested
elements.

Conor

Re: Wishlist of make like features.

[Peter Nordlund <pe...@lentus.se>]

Stefan Bodewig wrote:
> 
>  PN> * 2.  make -n: Dry-run. Don't actually run any commands; just
>  PN> print them.
>  >>  What kind of output would you want, the names of the targets, the
>  >> names of the tasks or the names and attributes of all tasks?
> 
>  PN> I thought of the same output as if the commands actually were
>  PN> executed.  So that you could combine this option with -verbose
>  PN> and -quiet.
> 
> You mean "[copydir] Copying 2 files to x/y/z" but don't do
> anything. 

Yes that is exactly what I mean.

> This might be trivial to implement but we'd need to modify
> every single task (well, <echo> might go unchanged). This is called
> SMOP I've been told 8^).

Yes, I understand that it might be quite some work ......


/Peter

Re: Wishlist of make like features.

[Stefan Bodewig <bo...@bost.de>]

>>>>> "PN" == Peter Nordlund <pe...@lentus.se> writes:

 PN> Stefan Bodewig wrote:
 >>  >>>>> "PN" == Peter Nordlund <pe...@lentus.se> writes:
 >> 
 PN> * 1.  make -k: Keep going when some targets can't be made.
 >>  If more than one target is specified on the command line or in
 >> the more general case?

 PN> I thought in the more general case. If I remember right that is
 PN> what make does.

I think so, yes. I'll take a look at it.

 >>
 PN> * 2.  make -n: Dry-run. Don't actually run any commands; just
 PN> print them.
 >>  What kind of output would you want, the names of the targets, the
 >> names of the tasks or the names and attributes of all tasks?

 PN> I thought of the same output as if the commands actually were
 PN> executed.  So that you could combine this option with -verbose
 PN> and -quiet.

You mean "[copydir] Copying 2 files to x/y/z" but don't do
anything. This might be trivial to implement but we'd need to modify
every single task (well, <echo> might go unchanged). This is called
SMOP I've been told 8^).

 PN> Maybe -verbose could take a numerical argument?
 
I'd prefer a symbolic one (syslog like as suggested).

 PN> When I run ant in the following style: ant compile > /dev/null.
 PN> I think that a build failure should show up on stderr, but as it
 PN> is made today, the build failure goes to stdout

I'll take a look at this rather soon.

Stefan

Re: Wishlist of make like features.

[Peter Nordlund <pe...@lentus.se>]

Stefan Bodewig wrote:
> 
> >>>>> "PN" == Peter Nordlund <pe...@lentus.se> writes:
> 
>  PN> * 1.  make -k: Keep going when some targets can't be made.
> 
> If more than one target is specified on the command line or in the
> more general case?

I thought in the more general case. If I remember right that is what
make does.

> 
>  PN> * 2.  make -n: Dry-run. Don't actually run any commands; just
>  PN> print them.
> 
> What kind of output would you want, the names of the targets, the
> names of the tasks or the names and attributes of all tasks?

I thought of the same output as if the commands actually were executed.
So that you could combine this option with -verbose and -quiet.

> 
> Printing some kind of command line like make does is not appropriate
> for many builtin tasks.
> 

- Ok, what I would like to have is mainly the "verbose" info for
the tasks, without all the stuff about properties settings.

>  PN> I find it a bit difficult to control the amount of output that I
>  PN> want from ant.
> 
> I remember some of your points have been addressed before, only other
> things have always gained a higher priority.
> 

- Yes, there are other stuff that has highere priority.

> It seems we need a logging level between INFO (what you see when you
> don't specify a command line switch) and VERBOSE (what you get when
> you say -verbose). Or the other way around, add an -extraverbose
> switch and lower the priority of most VERBOSE output to EXTRAVERBOSE.

Maybe -verbose could take a numerical argument? 
 
> Another point is that one might wish to control the logging level on a
> task by task basis.

Yes, maybe as I suggested (although I wrote property when I meant
attribute): 
with an attribute to the task e.g.
<javac verboselevel="4" .......

 
>  PN> When I run ant in the following style: ant compile > /dev/null.
>  PN> I think that a build failure should show up on stderr, but as it
>  PN> is made today, the build failure goes to stdout i.e. to
>  PN> /dev/null.
> 
> What would you expect if you say
> 
> ant compile -logfile /dev/null
> 
> My feeling is that there shouldn't be any output sent to stdout or
> stderr if the user specifies -logfile. If the user doesn't (i.e. all
> normal messages are sent to stdout) we could write the exception stack
> traces and everything logged with priority ERR to stderr. What do you
> think?

I agree with you, I think that your suggestion is good.

Regards,
Peter

Re: Wishlist of make like features.

[Stefan Bodewig <bo...@bost.de>]

>>>>> "PN" == Peter Nordlund <pe...@lentus.se> writes:

 PN> * 1.  make -k: Keep going when some targets can't be made.

If more than one target is specified on the command line or in the
more general case?

 PN> * 2.  make -n: Dry-run. Don't actually run any commands; just
 PN> print them.

What kind of output would you want, the names of the targets, the
names of the tasks or the names and attributes of all tasks?

Printing some kind of command line like make does is not appropriate
for many builtin tasks.

 PN> I find it a bit difficult to control the amount of output that I
 PN> want from ant.

I remember some of your points have been addressed before, only other
things have always gained a higher priority.

It seems we need a logging level between INFO (what you see when you
don't specify a command line switch) and VERBOSE (what you get when
you say -verbose). Or the other way around, add an -extraverbose
switch and lower the priority of most VERBOSE output to EXTRAVERBOSE.

Another point is that one might wish to control the logging level on a
task by task basis.

 PN> When I run ant in the following style: ant compile > /dev/null.
 PN> I think that a build failure should show up on stderr, but as it
 PN> is made today, the build failure goes to stdout i.e. to
 PN> /dev/null.

What would you expect if you say 

ant compile -logfile /dev/null

My feeling is that there shouldn't be any output sent to stdout or
stderr if the user specifies -logfile. If the user doesn't (i.e. all
normal messages are sent to stdout) we could write the exception stack
traces and everything logged with priority ERR to stderr. What do you
think?

Stefan