----- Original Message ----- From: "John Barstow" <[EMAIL PROTECTED]> To: "'Gert Driesen'" <[EMAIL PROTECTED]>; "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, July 01, 2003 7:48 AM Subject: RE: [nant-dev] Nant.VisualCpp.Tasks build failures
> Gert Driesen [mailto:[EMAIL PROTECTED] wrote: > > Do you have VS.NET installed ? The cpp compiler and stuff are not part of > > the .NET Framework. Is the C:\program Files\Microsoft Visual Studio .NET > > 2003\Vc7\bin directory in your path ? > Surprisingly, the cpp compiler *is* part of .NET framework. However the > compiler that is included may not be fully functional; which might be > causing the error. So it's part of the .NET Framework, but it's installed in the VS.NET directory ? Hmm, never really payed any attention that ... I'm running the tests on the .NET Framework 1.1 with VS.NET 2003 installed, and its working fine here. > The required directory is in the path. > > > Currently there's no multiple framework support for the cpp tasks, as this > > is not possible with the current framework implementation which means the > > cpp linker and stuff have to be in your path right now. I've got a batch > of > > changes ready that wil allow us to do that, but I'll hold off on them > until > > after you've created a new release. > Can you send me your changes privately or test them on a 1.1 machine? If > they enable the test suite to pass without breaking the other unit tests, > I'd recommend they go in as part of this release. Otherwise, we should > write up a release note that explains how to make this task work correctly > with multiple frameworks. The changes I've introduced allow us to have a framework specific configuration for all tasks, but the tasks themselves should also allow such configuration ofcourse. Right now, the cpp tasks do not allow a path to the commandline tools to be set. Actualy most of the existing tasks (that rely on external programs, eg. csc) only allow the name of the executable to be set and rely on other mechanisms to set the remaining part of the path, or just use the name of the exe and rely on it being in the path. I think we could in fact allow all tasks that derive from ExternalProgramBase to specify the full path directly using the NAnt configuration file (or the build file), as that will definitely increase the flexibility of NAnt. The way I've implemented the framework support right now, allows you to set the name of the executable (or any other attribute) for a task (or element) on a framework-level in the NAnt configuration file, as I didn't want to make any "major" changes (with the recent discussion about this in mind) . But this still requires another mechanism to get to a full path (eg. for the csc task, this is : combine the name of the executable with the Framework directory to get the full path to the c# compiler, which is done in FXCompilerBase), while in fact we could allow the full path to be specified directly for each task (that wants to). I'm not saying we should do this for all tasks, the csc task, for example, does not need this. But I don't think its a bad idea to allow it, but still use the current mechanism by default. Although these aren't that major changes, and altough I'd love to commit the current changes as soon possible, I still think it's not a good idea to make these changes this close to a new release ... unless you (and the rest of the NAnt community) think we can/should postpone the release a couple of days (or so). Anyway, I definitely would like to discuss this with Ian first, and get his view on this. We can perhaps even set-up a little meeting using MSN or Jagger or something, to discuss this in real-time. Gert ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
