[Nant-users] Including Nant build files

[Matt Trentini]

Heya Guys,

I'm trying to shift some common targets into one NAnt script and use
those operations from multiple NAnt scripts.

Something like this:

<!-- common.build -->
<?xml version="1.0"?>
<project name="Common Operations" default="output.message">
<property name="message" value="Test Message" />
<target name="output.message">
<echo message="${message}" />
</target>
</project>

And this:

<!-- (One of many) specific.build -->
<?xml version="1.0"?>
<project name="Specific operation" default="output.message">
<include buildfile="common.build" />
<property name="message" value="This is a much more specific message" />
</project>

Which works fine. :) What I'd like to do however is get project help
on one of the specific build files that included targets from both the
specific build file and the common build file. Ie, I'd like to be
able to do:

nant -buildfile:specific.build -projecthelp

And get it to display:

output.message

as a target. Currently that only happens if I query common.build.
Does that make sense?

Should I be structuring my targets differently or is there just no way
to currently do this?

Cheers,
Matt

PS I believe Ant has an import task which does something similar...

[Gary Feldman]

...Which works fine. :) What I'd like to do however is get project help
on one of the specific build files that included targets from both the
specific build file and the common build file. Ie, I'd like to be
nant -buildfile:specific.build -projecthelp
output.message
as a target. Currently that only happens if I query common.build.
Does that make sense?
Should I be structuring my targets differently or is there just no way
to currently do this?

It makes sense, but as far as I know there's no way to do it.

I'm not sure it will be the best approach in the long run, either. I've
been doing the same sort of partitioning into shared include files, and
I'm very happy with the resulting design. But as I work on this, I
create many small targets, based on the one object/target should do one
thing principle. Most of these aren't intended for the command line,
and just clutter up the -projecthelp listing, making the listing
worthless. By keeping the primary targets very simple (e.g. clean,
build, test, clean-all, build-all, test-all, etc.), I obviate the need
for projecthelp anyway. If I thought I really needed this sort of help,
I'd write a usage target that just printed the important targets,
perhaps with additional help and detailed help targets.

I can think of many ways that -projecthelp could be made more flexible
and powerful, including working with included build files, but not for
the 0.85 release.

Gary

[Merrill Cornish]

Matt,

I don't believe you can do what you would like to do. As I remember from some previous question, --projecthelp doesn't actually cause the NAnt file to be processed so <include> tasks and ${propertyname} substitutions aren't executed. Instead, --projecthelp merely reads the NAnt file serially looking for certain attributes in certain elements and reporting them.

Merrill

[Matt Trentini]

Thanks for all your help folks. A custom help task ought to do the
job. Still seems to me that -projecthelp should parse any include
tags but hey, I can live with that limitation! :)

Would anyone be interested in a patch for that behaviour? Or is it
undesirable (as it seemed to be for Gary at least)?

Cheers,
Matt

Post by Merrill Cornish
Matt,
I don't believe you can do what you would like to do. As I remember from some previous question, --projecthelp doesn't actually cause the NAnt file to be processed so <include> tasks and ${propertyname} substitutions aren't executed. Instead, --projecthelp merely reads the NAnt file serially looking for certain attributes in certain elements and reporting them.
Merrill

[Ian MacLean]

Post by Matt Trentini
Thanks for all your help folks. A custom help task ought to do the
job. Still seems to me that -projecthelp should parse any include
tags but hey, I can live with that limitation! :)
Would anyone be interested in a patch for that behaviour? Or is it
undesirable (as it seemed to be for Gary at least)?

Definately. I vaguely started looking at it a while ago but didn't get
much done. The current implementation uses an xslt stylesheet to process
the buildfile and generate the projecthelp output. Xslt probably isn't
really the right tool for this ( hey I was doing a lot of work with xslt
at the time and when you've got a hammer everything looks like a nail )
however some kind of custom parsing will likely be necessary - rather
than using NAnt's project class to load the includes. Remember that all
top level tasks in an included file get excuted at <include> time - not
ideal for -projecthelp if those top level tasks include things like
<copy> or <delete>.

Feel free to ping me or the list with any questions about the
implementation.

Ian

Post by Matt Trentini
Cheers,
Matt

Post by Merrill Cornish
Matt,
I don't believe you can do what you would like to do. As I remember from some previous question, --projecthelp doesn't actually cause the NAnt file to be processed so <include> tasks and ${propertyname} substitutions aren't executed. Instead, --projecthelp merely reads the NAnt file serially looking for certain attributes in certain elements and reporting them.
Merrill

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Nant-users mailing list
https://lists.sourceforge.net/lists/listinfo/nant-users

[Matt Trentini]

Heya Ian,

Post by Ian MacLean

Post by Matt Trentini
Would anyone be interested in a patch for that behaviour? Or is it
undesirable (as it seemed to be for Gary at least)?

Definately.

I take it that definitely was directed at the "interested in a patch". ;)

Post by Ian MacLean
I vaguely started looking at it a while ago but didn't get
much done. The current implementation uses an xslt stylesheet to process
the buildfile and generate the projecthelp output. Xslt probably isn't
really the right tool for this ( hey I was doing a lot of work with xslt
at the time and when you've got a hammer everything looks like a nail )
however some kind of custom parsing will likely be necessary - rather
than using NAnt's project class to load the includes.

XSLT may still be useful - we can use it to identify all of the
targets _and_ the include nodes. The target nodes we just print out
the name attribute and the include nodes we open up the specified
buildfile and recursively repeat.

I agree that using NAnt's project class wouldn't be the best way forward.

Post by Ian MacLean
Feel free to ping me or the list with any questions about the
implementation.

Thanks Ian. If I find some time in the coming weeks I'll give it a
shot. I'll be sure to ping you (and probably the dev list) if I get
stuck. :)

However, right now I'm more focussed on writing custom tasks and
possibly working on the solution task (the lack of custom build tasks
is a showstopper for me using that task) so this might have to take a
back seat for awhile.

Cheers,
Matt

[Gary Feldman]

Post by Matt Trentini
Thanks for all your help folks. A custom help task ought to do the
job. Still seems to me that -projecthelp should parse any include
tags but hey, I can live with that limitation! :)
Would anyone be interested in a patch for that behaviour? Or is it
undesirable (as it seemed to be for Gary at least)?

I didn't mean to suggest that that's undesirable. I think it's a good
idea, but a case can be made for something even more powerful.

Gary

[Merrill Cornish]

Matt,

-projecthelp should parse any include tags

I think the problem is with the camel getting his nose in the tent. :-)

If you parse <include> tasks, then you would also (I think) have to parse properties since the include pathname could be defined by property expansion. However, properties can be conditionalized by <if> tasks, so they have to be parsed, and properties get defaults by command line parameters so they have to be parsed. By the time you're finished, you may have processed most of the build file.

Merrill

[Matt Trentini]

Heya Merrill,

Post by Merrill Cornish
If you parse <include> tasks, then you would also (I think) have to parse properties
since the include pathname could be defined by property expansion. However,
properties can be conditionalized by <if> tasks, so they have to be parsed, and
properties get defaults by command line parameters so they have to be parsed. By
the time you're finished, you may have processed most of the build file.

Gotcha, all good points. I'll have to look into it some more obviously!

Maybe we can start with the simple version - it would still be useful
(at least to me!). ;) Then we can make a more thorough and correct
version later.

Ideally, it won't be that hard to do the full-on parsing. :)

Cheers,
Matt

[l***@encounterit.co.uk]

Post by Matt Trentini

Post by Ian MacLean
I vaguely started looking at it a while ago but didn't get
much done. The current implementation uses an xslt stylesheet to process
the buildfile and generate the projecthelp output. Xslt probably isn't
really the right tool for this ( hey I was doing a lot of work with xslt
at the time and when you've got a hammer everything looks like a nail )
however some kind of custom parsing will likely be necessary - rather
than using NAnt's project class to load the includes.

XSLT may still be useful - we can use it to identify all of the
targets _and_ the include nodes. The target nodes we just print out
the name attribute and the include nodes we open up the specified
buildfile and recursively repeat.

A quick and dirty implementation can be achieved with xslt and the
document function. Add the following template to deal with the include
elements

<xslt:template match="nant:include">
<xslt:value-of select="$space" />
<xslt:value-of select="stringutils:PadRight(@buildfile, 20)" />
<xslt:value-of select="$newline" />
<xslt:value-of select="$newline" />
<xslt:variable name="include"
select="document(@buildfile)/nant:project"/>
<xslt:apply-templates
select="$include/nant:target[string(@description) != '']" />
</xslt:template>

and then add the following to the end of the nant:project template

<xslt:text>Imports: </xslt:text>
<xslt:value-of select="$newline" />
<xslt:value-of select="$newline" />
<xslt:apply-templates select="nant:include" />

This will then add all the main targets of the included file at the end
of the help.

If you wanted this to be a more permanent solution you'd probably want
to do some more indenting for the imports.

Post by Matt Trentini
I think the problem is with the camel getting his nose in the tent. :-)
If you parse <include> tasks, then you would also (I think) have to parse properties since the include pathname could be defined by property expansion. However, properties can be conditionalized by <if> tasks, so they have to be parsed, and properties get defaults by command line parameters so they have to be parsed. By the time you're finished, you may have processed most of the build file.
Merrill

This is why it's a quick and dirty implementation. It only works for
include elements which don't have properties in. In my opinion the
easiest way around this would be to have a description attribute allowed
on the include element which would then be output as well. This could
then be used to describe the included file and how the properties affect it.

Richard
--
Richard Willis
Director
Encounter I.T. Ltd.
http://www.encounterit.co.uk

Address:
UNIEIlab, Unit 6, William Lee Buildings,
Nottingham Science and Technology Park,
University Boulevard, Nottingham, NG7 2RQ.

Telephone:
00 44 (0) 845 226 3057

Mobile:
07961 577 032

[Merrill Cornish]

Matt,

A simple version could parse <include> tasks with literal pathnames and quietly skip <include> tasks that reference properties. Not perfect, but it would work in many cases.

Merrill

[Bill Arnette]

Is there any way to create a property whose value is the list of resolved
files in a fileset, or failing that to create a fileset from a property?

What am I trying to do? I am trying to write a build file for a WiX project
that lists the source/target files only once and has source file/obj file
dependency checking. Here is my current build file:

<?xml version="1.0"?>
<project name="Dahmer" xmlns="http://nant.sf.net/release/0.85-rc3/nant.xsd"

default="all">
<property name="SOURCES" value="videopro.wxs SharedComponents.wxs
Graphs.wxs"/>
<property name="WIXOBJS" value="videopro.wixobj SharedComponents.wixobj
Graphs.wixobj" />
<property name="MSI" value="VideoPro.msi" />
<fileset id="OBJS">
<include name="*.wixobj"/>
</fileset>
<target name="all" depends="compile"/>
<target name="compile" depends="">
<exec program="candle" commandline="${SOURCES}"/>
<exec program="light" commandline="${WIXOBJS} -out ${MSI}"/>
</target>
</project>

This works fine, but there is no file dependency checking. How can I add
file dependency checking without adding the file names to multiple places in
the build file?

If I could create a fileset given a property, I could use the up-to-date
task for that. Or, if I could create property from a fileset, the SOURCES
property could be created from a fileset.

In the old days of MAKE we could do something like (ignoring inference
rules):
SOURCES=a.wxs b.wxs c.wxs
WIXOBJS=a.wixobj b.wixobj c.wixobj

VideoPro.msi : ${WIXOBJS}
light ${WIXOBJS} -out VideoPro.msi

a.wxs : a.wixobj
candle a.wxs

b.wxs : b.wixobj
candle b.wxs

c.wxs : c.wixobj
candle c.wxs

How do we do that with Nant?

[B***@avon-insurance.co.uk]

Bill,

Can't you use the refid? You are creating a fileset with an id (<fileset
id="OBJS">), and you can refer to that anywhere else by using:

<fileset refid="OBJS" />

Which you can wrap in an <uptodate> task. Alternatively, you could easily
knock up a bit of script to create a function that will convert the
fileset to a string. I think someone posted an example a few months back
if you search the mail archives.

HTH,

Bill






"Bill Arnette" <***@signalscape.com>
Sent by: nant-users-***@lists.sourceforge.net
18/08/2005 19:51


To: <Nant-***@lists.sourceforge.net>
cc:
Subject: [Nant-users] Property from fileset or vice versa?


Is there any way to create a property whose value is the list of resolved
files in a fileset, or failing that to create a fileset from a property?

What am I trying to do? I am trying to write a build file for a WiX
project
that lists the source/target files only once and has source file/obj file
dependency checking. Here is my current build file:

<?xml version="1.0"?>
<project name="Dahmer" xmlns="http://nant.sf.net/release/0.85-rc3/nant.xsd"

default="all">
<property name="SOURCES" value="videopro.wxs SharedComponents.wxs
Graphs.wxs"/>
<property name="WIXOBJS" value="videopro.wixobj SharedComponents.wixobj
Graphs.wixobj" />
<property name="MSI" value="VideoPro.msi" />
<fileset id="OBJS">
<include name="*.wixobj"/>
</fileset>
<target name="all" depends="compile"/>
<target name="compile" depends="">
<exec program="candle" commandline="${SOURCES}"/>
<exec program="light" commandline="${WIXOBJS} -out ${MSI}"/>
</target>
</project>

This works fine, but there is no file dependency checking. How can I add
file dependency checking without adding the file names to multiple places
in
the build file?

If I could create a fileset given a property, I could use the up-to-date
task for that. Or, if I could create property from a fileset, the SOURCES
property could be created from a fileset.

In the old days of MAKE we could do something like (ignoring inference
rules):
SOURCES=a.wxs b.wxs c.wxs
WIXOBJS=a.wixobj b.wixobj c.wixobj

VideoPro.msi : ${WIXOBJS}
light ${WIXOBJS} -out VideoPro.msi

a.wxs : a.wixobj
candle a.wxs

b.wxs : b.wixobj
candle b.wxs

c.wxs : c.wixobj
candle c.wxs

How do we do that with Nant?





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Nant-users mailing list
Nant-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users


As detailed in the company handbook, Avon Insurance has the facility to
monitor and read both incoming and outgoing communications by e-mail.

A copy of the company handbook can be found here: http://www.ho.nfumutual.co.uk/mutualnet/HANDBOOK/ITPolicies/ITSecure.htm





IMPORTANT
The information contained in this e-mail and any attachments is intended for the addressee only
and may contain legally privileged or confidential information. If you are not the intended
recipient you must not use, disclose, copy, distribute, alter, or take any action in reliance
on the information and Avon Insurance plc will not accept liability for any loss or damage howsoever
arising, directly or indirectly in reliance on it and gives no warranty or representation as to its
accuracy or reliability. If you are not the addressee, please notify us immediately on 01789 202121*
and delete the material from your computer and destroy any copies.

Avon Insurance plc reserves the right to monitor and record incoming and outgoing email messages for
the purposes of investigating or detecting unauthorised use of its system and ensuring its effective operation.
Avon Insurance plc will not accept liability for any loss or damage as a result of any virus being passed on.

Avon Insurance plc (No. 209606).
Registered in England. Registered Office: Arden Street, Stratford upon Avon, Warwickshire CV37 6WA.
Authorised and regulated by the Financial Services Authority.
A member of the NFU Mutual group of companies and the Association of British Insurers.

*For security and training purposes, telephone calls may be recorded and monitored.