forwarded from Richard Poole
-----------------------------------------

Hi Ian,

I'm still having difficulty posting to the list. I get this error: -

-----
Your message did not reach some or all of the intended recipients.

     Subject:   Isn't all this XML just abstracted C#?
     Sent:      11/08/2004 16:09

The following recipient(s) could not be reached:

     'NAnt Users Mailing List' on 11/08/2004 16:09
           The recipient name is not recognized
        The MTS-ID of the original message is: c=GB;a= ;p=Eurosoft (UK)
Lt;l=ESUK02-040811150846Z-4670
           MSEXCH:IMS:Eurosoft (UK) Ltd:EUROSOFT-UK:ESUK02 3550 (000B09B6)
550 Sender verify failed
-----

Anyway... below is what I was trying to post. Is there any chance you could
post it on my behalf? :)

Cheers,
Richard.

-----Original Message-----
From: Richard Poole Sent: 11 August 2004 16:09
To: 'NAnt Users Mailing List'
Subject: Isn't all this XML just abstracted C#?



Hi,

I'm just thinking out loud, so excuse me if this sounds utterly stupid, but
why use XML for build scripts? I realise XML helps to a certain degree with
portability, but surely a NAnt build script can only be as portable as the
tasks it uses... all of which are written in C#, making them inherently
portable anyway. So aren't all these XML elements ultimately just abstracted
C# method calls?

For example, I've been writing two tasks called 'wcc' and 'wl' so that I can
use the Watcom 16-bit C/C++ Compiler and Linker with a similar XML
abstraction to that of the 'csc' task. I'd say about 1/3rd of the code I've
written is just there to support the XML abstraction layer!

So my question is this: -

Can anyone suggest why writing an entire build script in C# would be any
worse than writing it in XML? Instead of being a script runner, NAnt would
be an execution framework (like NUnit), and a bunch of utility classes
(tasks without the unnecessary XML abstraction).

Example build script (if you can call it that anymore): -

using NAnt.Core.Tasks;
using NAnt.DotNet.Tasks;
using NAnt.SourceControl.Tasks;

[BuildFixture]
public class MyBuildScript
{
        // Checkout projects that we depend on.
        [BuildTarget]
        public void Checkout(BuildOptions options)
        {
                Cvs.Repository = "cvs";
                Cvs.Username = options["CvsUsername"];
                Cvs.Password = options["CvsPassword"];
                Cvs.Checkout("ProjectA");
                Cvs.Checkout("ProjectB");

                NAnt.Build("ProjectA\ProjectA.build", "Checkout", options);
                NAnt.Build("ProjectB\ProjectB.build", "Checkout", options);
        }

        [BuildTarget]
        public void Build(BuildOptions options)
        {
                // Build any sub-projects that we rely on.
                NAnt.Build("ProjectA\ProjectA.build", "Build", options);
                NAnt.Build("ProjectB\ProjectB.build", "Build", options);

                // Build this project.
                Csc.Sources = "*.cs";
                Csc.References += "ProjectA\bin\Release\ProjectA.dll";
                Csc.References += "ProjectB\bin\Release\ProjectB.dll";
                Csc.Target = "MyProject.exe";
                Csc.Compile();

                // Run unit tests on our project.
                NUnit.Test("MyProject.exe", "MyProject.Tests.dll");
        }
}

Example command line invocation: -

nant Checkout -D:CvsUsername=<username> -D:CvsPassword=<password>

Stupid or reasonable?

Cheers,
Richard.

-----Original Message-----
From: McCullough, Gary [mailto:[EMAIL PROTECTED]
Sent: 11 August 2004 14:30
To: Nant-Users (E-mail)
Subject: RE: Property change-suggestions, was RE: [Nant-users] can't
overwrite property


OK, here's my idea NAnt world:

Scopable properties
Parameter variables
Return values

In other words, I want it to work more like a functional language. The
closest model I can think of is XSLT. It seems to me that these elements
could greatly simplify the coding of complex build script logic without
introducing many changes or extensions to the NAnt language. In fact, I
would argue, that the fact that NAnt doesn't have any of these 3 ideas
actually makes it harder for newcomers to learn (at least it did for
me).

Scoping could be done implicitly as it generally is in scripting
languages. The scope of a variable (property) is the container in which
it is declared. So a property declared inside a template element is only
visible within that template; a property declared outside a template is
global to that build.

Parameter variables could be done something like xslt:

<call target="myTarget">
        <with-param name="myParam" value="Foo" />
</call>

Returns could also follow an xslt-like pattern:

<property name="myResult">
        <call target="myTarget">
                <with-param name="myParam" value="Foo" />
        </call>
</property>

And here's the target (it's a little different from XSLT in that build
files aren't made to produce text output, so it makes sense to
explicitly return something (XSLT just returns whatever the template
spits into standard out)):

<target name="myTarget">
        <param name="myParam" />
        <return>true</return>
</target>

It seems to me all 3 extensions could be introduced without introducing
breaking changes. Except for implicitly scoping property declarations.
Might want to think carefully about that one.

________________________________

Gary McCullough -----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Troy Laurin
Sent: Tuesday, August 10, 2004 11:10 PM
To: Nant-Users (E-mail)
Subject: Property change-suggestions, was RE: [Nant-users] can't
overwrite property


I'm sure people are sick of getting a slough of mails from me, so I'll
combine these ones :-)


Richard Poole wrote:
I'm relatively new to NAnt so please forgive me if this is a
rubbish/old idea. :)

--- C# snippet ---


public void MyFunction() { int a = 2; // const or not... { int a = 4; // ...a will now be equal to 4... } // ...but now a equals 2 again. }

--- NAnt build script snippet ---

<property name="a" value="2" /> <!-- readonly or not... --> <someelement> <property name="a" value="4" /> <!-- ...a will now be equal to
4... -->
</someelement> <!-- ...but now a equals 2 again. -->

What about the following C# scenario:
public void MyFunction() { int a = 2; // const or not... { a = 4; // note non-redefinition of a
} // ...a now equals 4!!
}


How could this be expressed in a NAnt script?

It might be possible to introduce a 'scope' attribute to the property
task, but there are quite a few other tasks which set property values...
being able to determine the scope for these variables would mean a
potential blowout in extra attributes, making NAnt harder to learn for
newcomers.


Global-scope properties (or variables) need to be available... a simple example requiring this is an 'init' target, which creates a log file or folder corresponding to the current time, and then sets the path to this file/folder in a property, so other targets can write their logs to the correct location.

McCullough, Gary wrote:
I like this idea. But even better I like the idea of making explicit parameters. Something I've mentioned before. Parameters and locals would go a long way toward simplifying build file logic, I think.

For instance, adapting XSLT conventions, suppose you had a construction like this in your build file:

<param name="outputDir" default=".\output\" />

And you fired your build file, overriding the default outputDir value, something like this:

Nant.exe myprogram.build -D:outputDir="c:\builds\myprogram\bin\"

However, we still have to figure out how to handle the breaking change it would introduce.

I find this idea intriguing, but I'm concerned that the complexity is subtle and potentially fatal.

The biggest issue that I can see is how to differentiate between
properties and parameters?  If they use the same expression syntax ${}
to access their values, then how do you deal with name conflicts?


Gert Driesen wrote:
The easiest, and in my opinion best, solution is to mark the properties that you want to be able to override on the command line with overwrite="false".

That way the property task will not attempt to overwrite the value of the property (that was, for example, specified on the command line).

I think that this, plus changing commandline parameters to not be read-only would remove much of the confusion for people new-come to NAnt. There would of course be a ramp-across cost for Ant users, but there have already been enough changes between Ant and NAnt to suggest the need for a migration guide. The addition of a function to determine the command-line value of a parameter should cover all cases?


Comments?

-T

Disclaimer Message:

This message contains confidential information and is intended only for
the individual(s) named.  If you are not the named addressee you should
not disseminate, distribute or copy this e-mail. Please immediately
delete it and all copies of it from your system, destroy any hard copies
of it, and notify the sender. E-mail transmission cannot be guaranteed
to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain
viruses. To the maximum extent permitted by law, Immersive Technologies
Pty. Ltd. does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.


------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users


DISCLAIMER: The information contained in this e-mail is confidential and may
be privileged. It is intended for the addressee only. If you are not the
intended recipient, please delete this e-mail immediately. The contents of
this email must not be disclosed or copied without the sender's consent. We
cannot accept any responsibility for viruses, so please scan all
attachments. The statements and opinions expressed in this message are those
of the author and do not necessarily reflect those of the company. The
company does not take any responsibility for the views of the author.





--
Ian MacLean, Developer, ActiveState, a division of Sophos
http://www.ActiveState.com




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users

Reply via email to