RE: [NAntC-Dev] Proposed change to vb6 task

[Nick Zigomanis]

Hi Subbu,   Yes, in our case, we have two major projects, one has about 1000 vb6 projects, and the other has between 3000-4000, so minimizing build times is very important for us.   I like your idea, about passing something to the vb6 task. I had similar thoughts as well, sort of like a pre-compile attribute, which does some work when the vb6 task determines that a rebuild is required (we update version info, company info, trademark info, etc, etc.).   One of the things that makes this problematic for us is that we use clearcase for the source control tool (clearcase itself is not the problem). The only way to modify the vbp is to actually checkout and checkin the file (and then the timestamp gets updated anyway). This is what we were doing originally, but the checkout/checkin operation itself slowed down the build, and you don’t know beforehand whether you need to do the checkout. To make things worse (for us) is that we are using UCM with clearcase. Essentially, what this means is that when a deliver operation is performed (deliver = integrate), it would also want to deliver all the changed vbp files. We didn’t want to do this, and it was time consuming. The deliver operation in clearcase is quite an expensive operation in terms of time and resources. So instead of now doing the checkout/checkin, we make a copy of the vbp file, and do some substitutions. This is quite a quick operation, but you don’t know before hand whether you need to do this or not, so at the moment we always make the copy.   For the time being, I’ve just added a –checkvbptimestamp attribute to the vb6 task here, and in our case we set this to false.   This is not the ideal solution, but was an extremely quick and simple fix, but I would prefer something better, along the lines that you were talking, and have the vb6 task be able to do something else, but only in the case where a recompile is needed.   Regards, Nick. From: Subbu Balakrishnan [mailto:[EMAIL PROTECTED] Sent: Wednesday, 20 October 2004 5:39 PM To: Nick Zigomanis Cc: [EMAIL PROTECTED] Subject: RE: [NAntC-Dev] Proposed change to vb6 task   Hi Nick   Build avoidance is always a good idea!!   I understand what you are trying to achieve now. Recognising the fact you already have a good functioning mechanism would it still be a good idea to achieve the same result by another route:   Pass parameters to the vb6 task i.e MajorVer, MinorVer etc. that only get wriiten to the vbp file (prior to the compile but after it has been determined that files and/or refs have changed and a compile is required). These properties could be global to the .build file and used for other purposes as well. Or you could read a config file with all the global settings. I haven't thought this through completely so you'll have to forgive me if there are major holes in it!   The reason I'm interested in all this is because I am desperately trying to get our 250+ COM components build off a proprietary build tool to NAnt and coming up against similar problems. I would be very interested in swapping war stories if possible.   I know its a bit late in the day to integrate vb6 into NAnt but someone has to do it!   Regards Subbu -----Original Message----- From: Nick Zigomanis [mailto:[EMAIL PROTECTED] Sent: Wednesday, 20 October 2004 4:16 PM To: Subbu Balakrishnan Cc: [EMAIL PROTECTED] Subject: RE: [NAntC-Dev] Proposed change to vb6 task Hi Subbu,   In theory, yes. But in actuality, we try to use build avoidance to minimise what we build.   So on subsequent builds, or patch builds, we only want to build projects whose source files or references have changed. We let the vb6 task determine whether the source or references have changed (as it should), and whether a rebuild is required, however, we don't know before hand whether a rebuild will be required, so we don't know whether to update the version info. If we update the version info before the vb6 task, then everything will get rebuilt, if we don't update the version info, then we may have compiled binaries with the wrong version info in it.   The easiest solution (for us), is to update all the project files with the new version info (which is a very quick process), even though in actuality, they don't all require a rebuild, and then to let the vb6 task build only those projects whose source or references have changed. To do this, we want to ignore the timestamp on the vbp file.   Regards, Nick. From: Subbu Balakrishnan [mailto:[EMAIL PROTECTED] Sent: Wednesday, 20 October 2004 3:31 PM To: Nick Zigomanis Cc: [EMAIL PROTECTED] Subject: RE: [NAntC-Dev] Proposed change to vb6 task   Hi Nick   Maybe I'm missing something very obvious here ... but wouldn't you want the versioning, company info etc. compiled into the binary therefore necessitating a build when the project file is changed?   Regards Subbu -----Original Message----- From: Nick Zigomanis [mailto:[EMAIL PROTECTED] Sent: Wednesday, 20 October 2004 2:50 PM To: [EMAIL PROTECTED] Subject: [NAntC-Dev] Proposed change to vb6 task Hi all,   Currently the vb6 task in determining whether a rebuild is required checks the following:   -          Project file -          Source files -          References (optional)   The checking of references can be controlled with an attribute.   What I'm proposing is that the checking of the project file is also controllable with an attribute (default value = true).   The reason for this is that in our case, our formal build will always generate a copy of the  project files with all the necessary information in it (versioning, company info, etc, etc) prior to the actual compilation taking place, so I don't want to check the timestamp on the project file because it would always cause a rebuild.   The change is fairly trivial, and there is no change to existing functionality. I actually have this change in my local environment, and have been running it for several weeks now.   What do you think?   Regards, Nick.