Thanks, I missed the part about TLBImp/TLBExp. I've thought about this a while longer, and I don't see a one-step solution that solves the problem for everyone concerned unless...
One of my concerns is putting stuff in the config file that would be modified by the end-user. Yes, sure you can customize it if you really need to, but then getting updates are a little hard to maintain. It may be the case that I want a user/local "buildfile" that contains only properties to set. Maybe I want something like a ".nantrc" for NAnt. (Ant has a .antrc.) As an example; if I'm working with the NAnt sources, I want to freely get new changes to the config files at any time. I also want to be able to run the tests (VisualCpp comes to mind) without modifying the appropriate files to tell NAnt where my compiler lives. If I can set some properties (i.e. visualCPPtoolsdir) in a "non-distributed" file, then the VisualCpp tasks could notice this being set and work correctly, even when I get a third party build file. I suspect that a ".nantrc" solution is easiest, however an implied Include of a buildfile seems somewhat attractive. Could easily cause grief. Does any of this sound interesting? -----Original Message----- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 7:09 AM To: Tharen D. Debold Cc: [EMAIL PROTECTED] Subject: Re: [nant-dev] Path dependencies for VisualCpp/some Win32 tasks Tharen , TLBImp, TLBExp already use the current framework to find their locations - post 0.8.3 anyway - you should try out a nightly build. VisualCpp tasks are a different matter however. Tasks that wrap .net framework executables are currently located using the information in the config file and thru the use of the ProgramLocation attribute as follows: [TaskName("tlbexp")] [ProgramLocation(LocationType.FrameworkSdkDir)] public class TlbExpTask : ExternalProgramBase { I'm not sure how we'd go about extending that mechanism to accomodate cl.exe and friends. One option would be to have a visualCPPtoolsdir property that can be set in the config file or updated by setting a property in the buildfile. Ian > There are currently several tasks that require their "program" to be > on the current path; is this the behavior that everyone uses/expects? > > I'm referring to things like TLBImp, TLBExp, cl, Lib, Link, etc. > > In our environment we have to change between compilers and such rather > frequently, and so we prefer to not have these on our paths, but > instead be in the build system (currently make) via properties/variables. > > I'd like to do something to correct most of these NANT tasks; I have a > few ideas, but I'm checking around for others. > > To complicate life, some programs (notably CL) need more than one > directory on the path; however they are related and might be able to > be inferred if given a base path. We might also want to use a base > path (if supplied) to set the default value for include/lib > directories in this scenario. > > Ideally, there should be a way to default this for the current machine > so that it did not have to be set for each compile. I'd sure love to > be able to build NANT and run the VisualCpp tests without having to > muck with my environment each time... > > Tharen > ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
