Community
Participate
Working Groups
This bug is used to track enhancements to the wtpbuilder to verify that the basic setup required is met for running a build.
Created attachment 207801 [details] Proposed enhancement to check that cvs and grep are installed
I'll make a few comments and ask some questions on this patch, though I've not applied it to my local copy nor "tried it out". 1. It is an excellent idea. 2. The cvs check is likely adequate and in a good place (at the very beginning). 3. The grep check I have questions/comments about. 3A: question: What purpose is served by the condidtion + <equals + arg1="${env.BASEOS}" + arg2="win32"/> Is the goal to do something different with grep on windows? If so, there's may be better ways on the <exec command itself ... where environments can be specified so that grep wont' run on windows, say. And, I really am just asking ... I don't understand that that piece of code is trying to do. 3B: the comment: If the purpose of the grep check is to really fail the build if grep is not present then 1) that might be a little more than needed, if somoene is just doing a local "test build" ... they wouldn't necessarily need the "fast fail quick check"? But more important, 2) they might not get this failure for quite a while ... the build might do a lot of work (30 minutes or more?) before getting to that part and then failing. If the purpose is to really check the system for all required/recommended prereqs, then I'd suggest it all be one in one place, up front, at beginning of first build.xml file (where cvs currently is, I think). And, then, if done that way, the prebuild task itself should only print "echo all build system prereqs passed", and it itself have "depends" tasks that check for various things ... cvs being one ... grep maybe another .... that way, it would be easy to add/modify in the future, such as to check for git, check to make sure important variables have been set, etc.... or, what ever is deemed useful as its use evolves. The point is, might be best to test everything up front. Each of the depends tasks for prebuild could either fail, or the deluxe solution would be to set a flag, so everything is "tested for" and user informed about each, rather then run, be told cvs is needed, run again, be told grep is needed, run again, told that something else is needed, etc. But it is a great idea. Both CVS and grep are pretty much "given" on linux boxes .... at least the ones I have used/installed. Is this an issue because you are using windows? Or, do you use a linux that just happens to not have them? If using windows ... there will likely, eventually, be problems with "path name lengths" at some spots ... but, maybe those could be worked around or fixed as well? I know lots of people would like to be able to do a local build on windows (for some reason :) Good luck.
Thank you David for your comments. Yes I run the Dali build on Windows because I don't have a linux machine available all the time. Both cvs and grep are available for Windows; I am using CVSNT and GNU Grep. But the only operation in the wtpbuilder that is not compatible on Windows is: <exec executable="grep" outputproperty="reasonFailed" resultproperty="returnCode" errorproperty="ignoredErrored" error="/dev/null" failonerror="false"> <arg line="-s --max-count 1 --after-context 20 --before-context 10 --regexp='${stringToCheck}' ${resource}"/> </exec> because the "error=/dev/null" on Windows will cause a FileNotFoundException: Execute failed: java.io.FileNotFoundException: J:\dev\null (The system cannot find the path specified) This is why I have set "error" to the variable grepErrorLog, where: <condition property="grepErrorLog" value="${env.LOG_DIR}/${projectname}/grepError.log" else="/dev/null"> <equals arg1="${env.BASEOS}" arg2="win32"/> </condition> This will make sure that errors will be redirect to a file in the ${env.LOG_DIR} on Windows, and to /dev/null on other OS (I assumed that nobody is trying to run the build on Mac). Let me know if there is a better way to do this. I concur with you that it will be more useful to check whether grep is installed at the beginning rather then during the "fast fail quick check", and I will update the patch with the corrections. Thanks.
Ok, if the /dev/null thing is what is causing and issue, I think you should just change it to the property you suggest on windows, and do it the same on linux and windows ... not sure why I set it to /dev/null ... but, can't imagine it is for any thing very significant. (Minor tip: if you were going to put in OS specific function, probably best to use ${os.name} as that is the "java property" and not specific to Eclipse. I'm guessing that piece of code runs in Eclipse's antRunner ... but, there are some parts of our script that do not run in Eclipse's antRunner (just plan ant), so the "os.name" is more general, generic, portable way to do it. I don't know much about it, other than what's in the OS description in ant's <exec task description).
Created attachment 207940 [details] Proposed enhancement to check that cvs and grep are installed David, thanks for the tip. I have removed the OS test, now all errors are logged to ${env.LOG_DIR}. Carl, Let me know when is the best time to apply this patch, thanks.
Created attachment 207951 [details] Proposed enhancement to check that cvs and grep are installed I refactored the system verification code into a new script that can be reused in the future. The new script is named checkSystemPrereq and is located in scripts/build.
I have applied the patch in version v201112202339.
