Hi Ian, First off, I really appreciate the responsiveness from both you and Gert with my questions.
I know that pre-1.0 releases are not expected to be backwards compatibile, but, I still think it's good to try for it. So, I humbly vote for option A, to leave the get-NNN() functions as is and add get-current-NNN() versions. I'm sure other people are aware of the current behavior. Thus, their scripts may depend on the side effect of get-buildfile-path returning the include'ing file, rather than the include'd file. Thanks again, Steve --- Ian MacLean <[EMAIL PROTECTED]> wrote: > Ian MacLean wrote: > > > Gert Driesen wrote: > > > >> > >> > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On Behalf Of > > >>> Steve Jansen > >>> Sent: vrijdag 3 december 2004 17:19 > >>> To: [EMAIL PROTECTED] > >>> Subject: [nant-dev] <include> task question > >>> > >>> Hi again, > >>> > >>> I have a question about the <include> task and the > >>> project::get-buildfile-path() function. > >>> > >>> I would like to know if there is a way to get the path of an > included > >>> build file, rather than the containing build file, from withing > the > >>> included file. > >>> > >>> Example: > >>> > >>> C:\folder\project.build > >>> ----------------------- > >>> <project> > >>> <include buildfile="..\include.build" /> > >>> </project> > >>> > >>> C:\include.build > >>> ----------------------- > >>> <project> > >>> <echo message="${project::get-buildfile-path()}" /> > >>> </project> > >>> > >>> > >>> In this case, the message display is "C:\folder\project.build", > but, I > >>> need to find a way to have a function return "C:\include.build". > >>> > >>> Any suggestions? > >>> > >> > >> > >> As far as I know this is not possible. > >> > >> > >> Ian: do you have anything to add to this ? > >> > >> > > Actually whenever we load a file we store the location map - > mapping > > each xml node to a file and line-number. So the information is > there - > > the major issue I see is that you would need to obtain the > task/Target > > object that is being referenced at the function call site. So in > the > > example above : > > > <snip> a bunch of unnecessarily complicated stuff </snip> > > It turns out its actually quite simple. We already pass a Location > reference when we expand properties ( ie when functions get evaluated > ) > Properties.ExpandProperties(attributeValue, Location); > This Location object contains the path of file where that property > was > defined. So its not too hard to pass that location on to the > FunctionSet > classes via their constructor. I have this working locally > > such that : > > <project name="include" > > <echo message="this file is :${project::get-buildfile-path()}" /> > <echo message="main file is: > ${project::get-master-buildfile-path()}" /> > </project> > > when included in another file called "Simple.build" produces : > > Buildfile: file:///K:/dev/test/csharp/GetBuildFileTest/Simple.build > Target(s) specified: run > > [echo] this file is > :K:\dev\test\csharp\GetBuildFileTest\include.build > [echo] main file is: > K:\dev\test\csharp\GetBuildFileTest\Simple.build > > > Now i just have a question on the naming. Should we : > > A) keep get-buildfile-path() as it is returning the the including > file > and add a get-current-file-path() function or > > B) change get-buildfile-path() to return the current file and add a > project::get-master-buildfile-path() function to return the including > > (ie master ) file . > ( as demonstrated above ) > > > Ian > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > _______________________________________________ > nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
