----- Original Message ----- From: "Martin Aliger" <[EMAIL PROTECTED]> To: "'Gert Driesen'" <[EMAIL PROTECTED]>; "'mike61079'" <[EMAIL PROTECTED]>; <nant-developers@lists.sourceforge.net> Sent: Wednesday, August 02, 2006 11:16 AM Subject: RE: [nant-dev] VSWebCache ObjectDir <solution>
>>> But I'm not sure, if using _any_ cache is good thing. >> >> I understand, but we should remain compatible with VS where >> possible and in this case it's even necessary (for creating >> strong named assemblies). > > Could you clarify that strong name thing, please? > VS compatibility is a good thing, but I don't see it as necessarity in my > case. We have extra features in solution, and maybe ability turning off > something VS does, is not so bad as well. Anyway, we need strong names > support in any case, that's sure. For csc to be able to resolve the relative path specified in AssemlyKeyFile in the same way as Visual Studio, we need to store our intermediate build output in the same folder structure. >> > I want to do CLEAN build, so I <delete> all output files, all "obj" >> > folder and still - there is hidden cache! Even >> non-documented cache. I >> > don't see this as the right way... >> >> For this, I've been meaning to introduce a clean mode for >> the <solution> task, but I haven't yet found time for it (pfffff). > > No problem - we are all busy :-) > >> No interim files is not an option: this would result in very >> bad performance for embedded resources as they would have to >> be recompiled on every run. > > Yes - it is. But sometimes it's not a problem. I do not mind if nighly > build > takes 2 hours instead of 1 at all. I usually sleep in that time anyway :-) Would a clean mode help you sleep better, or do you want to get rid of the VSWebCache for another reason (eg. for parellel builds, although you'll have this problem too with local obj dirs) ? >> > btw: could be solution compiled completely without obj folders? I >> > think some very old NAnt do not used them (0.84?) Or >> alternativelly - >> > could we use one folder (say c:\temp) for obj folders of >> all projects >> > in the solution? >> >> No, we must use the same folder structure as Visual Studio. >> If not, we run into problems with relative paths (in the >> AssemblyKeyFile assembly-level attribute). > > Is this totally needed? Say - other than AssemblyKeyFile relative path > will > broke? This could be documented behaviour of such an attribute > (interim-path) Ofcourse, but I'm afraid such an attribute might introduce more issues than it will solve. Same thing goes for the outputdir attribute that we have already. If it were up to me, we'd lose support for it immediately. <solution> task is there for compatibility with Visual Studio, if users want total control then they should use the individual compiler tasks. >> Also, a temp directory should only be used for temporary >> files, and intermediate build output cannot be considered temp files. > > Yes - temp was bad example. > In fact, obj folders are not so bad. They are local to sourcecode, one is > used to them from VS etc. But VSWebCache is bad in my eyes. That is > something like static variable in multithreaded application. You never > know, > when and what it broke. I agree, but I'd hate introducing a new attribute for each indivual usage scenario. Gert ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
