From: Wheeler, F. W \(Research\) <wh...@cr...> - 2005-10-03 13:48:01
|
Miguel, It would be great to have additional Dart builds for Visual Studio 7 = .NET. There is a Win2k_=ADmsvc-7.=AD0_=ADRelease build, but there were = a lot of changes between 7.0 and 7.1. I'm not sure whether the = WinXP-msvc7-Debug build is 7.0 or 7.1. It is probably 7.1, but the more = the merrier, especially if one of your nightly builds is a Release = build. So thanks for giving this a go. Why not just do your Debug and Release builds in separate build trees? = This will not use a significant amount of additional space, since the = bulk of the space will be used by the objects and libraries, not the = directory structure. Cmake will more readily handle that setup and that = is what most people do. It is also easier to keep a separate source = tree for each dashboard build. The local space required for a source = tree is much less than that of the build tree, and don't worry about the = CVS traffic on the server. Again this is what most people do and is = what cmake most readily supports. Some have tried to get multiple = nightly builds to work off the same source tree. At best it is = difficult. I think it is not worth the effort. By the way, I'm not sure whether you are implying this in your email, = but I would not recommend doing development or making changes inside = your dashboard build source trees. Local changes will affect the = dashboard, which is not too big a deal since local changes will also be = shown on the dashboard. CVS update conflicts can be a bigger headache. Fred Wheeler > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...]On Behalf Of Miguel A. > Figueroa-Villanueva > Sent: Monday, October 03, 2005 4:34 AM > To: vxl...@li... > Subject: [Vxl-users] problems submitting nightly build with ctest for > debug/release >=20 >=20 > Hello, >=20 > Please let me know if I should post the question in the CMake=20 > lists and=20 > not here. >=20 > I'm not sure if there is too much interest in having another nightly=20 > build for a: >=20 > - OS: WinXP Pro with SP2 > - Compiler: Visual Studio 7 .NET 2003 > - Machine: AMD Athlon XP 2400+ 2GHz 1GB DDR RAM > - cmake and vxl updated daily from cvs >=20 > But since I am trying to get into the habit of keeping my vxl build=20 > up-to-date automatically, I figured it wouldn't be much more work to=20 > test and submit the build. BTW, I'm running everything from=20 > the cygwin=20 > bash shell, and using cygwin tools except for the Compiler, and CMake=20 > (which is built with MS VS 7.1). >=20 > I have successfully built vxl and submitted it as Nightly and=20 > Experimental a few times. And I built the debug and release versions=20 > using something like: >=20 > - devenv.com /build Release(or Debug) /project ALL_BUILD >=20 > The problem that I am having is that I can't get them built=20 > using ctest.=20 > That is build both the release and debug configurations in the same=20 > binary tree (I have source and binary trees separate) and=20 > submit results=20 > for both of them together or separately. I definitely want to=20 > keep both=20 > configurations in the same tree and I can't afford to erase=20 > everything=20 > daily. >=20 > I have tried several things, but basically this is what I thought I=20 > should be doing (after reading several documentation pages,=20 > cmake book,=20 > and searching everywhere I could think): >=20 > "${MYCTEST} -D NightlyStart" > "${MYCTEST} -D NightlyUpdate" > "${MYCTEST} -C Release -D NightlyConfigure" > "${MYCTEST} -C Release -D NightlyBuild" > "${MYCTEST} -C Release -D NightlyTest" > "${MYCTEST} -C Debug -D NightlyConfigure" > "${MYCTEST} -C Debug -D NightlyBuild" > "${MYCTEST} -C Debug -D NightlyTest" > "${MYCTEST} -D NightlySubmit" >=20 > where ${MYCTEST} is set to the ctest program path. >=20 > This, however, builds the release version in lib/release, but doesn't=20 > build build lib/debug files. I think it might have to do with=20 > clearing=20 > some files... >=20 > Any insight on how to solve this issue will be greatly appreciated. >=20 > Thanks, Miguel >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads,=20 > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users >=20 |
From: Wheeler, F. W \(Research\) <wh...@cr...> - 2005-10-03 18:37:12
|
> I can do this... the only reasoning behind having both in the=20 > same build=20 > tree is that when I include the vxl libraries in my projects (using=20 > UseVXL.cmake in the CMakeLists.txt), the MSVS project built=20 > for my code=20 > includes the correct set of vxl libraries (debug or release) just by=20 > selecting debug/release in my project. I can see how this would be nice, so hopefully you can get this working. > > It is also easier to keep a separate source tree for each=20 > dashboard=20 > build. >=20 > I'm not sure I got this... Even if I don't modify the vxl=20 > source, should=20 > I still have separate source trees for each build? I thought nothing=20 > gets changed in the source tree by the build process... The dashboard builds will cvs update the source tree, keep track of what = files get updated, and report cvs updates and local file changes to the = builds server. If you do 2 builds off the same source tree, then they = may try to cvs update the tree at the same time, or one will report the = correct file updates for the day and the other will report no updates. = None of this is too big a deal as long as you are aware of these issues. > > By the way, I'm not sure whether you are implying this in=20 > your email,=20 > but I would not recommend doing development or making changes inside=20 > your dashboard build source trees. >=20 > Again, I'm not modifying the vxl source tree. My source code=20 > uses vxl in=20 > a separate tree structure. However, this is something I'll=20 > keep in mind=20 > since I do look forward to adding my "two cents" to the vxl effort. An advantage of keeping a separate source tree and build for your own = work is that you can update it when you want, and when you see that the = dashboard is reporting no errors. If you use your automatic nightly = build for your work then you might get stuck someday when some bad code = gets checked in to cvs and your build is broken. Even if everything = works, trivial changes to the source may cause your own code to rebuild = because libraries and header files have had their timestamp updated. Fred Wheeler |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2005-10-03 18:23:44
|
Fred, Amitha, all, First of all thanks, and I'll give the question a go in the CMake forum.=20 I'll also post any information I find out after I get things working as=20 Amitha suggested. Also, thanks to all for a great set of libraries! My questions about Fred Wheelers comments below: > Why not just do your Debug and Release builds in separate build trees? I can do this... the only reasoning behind having both in the same build=20 tree is that when I include the vxl libraries in my projects (using=20 UseVXL.cmake in the CMakeLists.txt), the MSVS project built for my code=20 includes the correct set of vxl libraries (debug or release) just by=20 selecting debug/release in my project. I don't know if having separate=20 trees will affect this behaviour... In any case, it seems it will be=20 easier to deal with this than with building debug/release vxl libs in=20 the same binary tree. > It is also easier to keep a separate source tree for each dashboard=20 build. I'm not sure I got this... Even if I don't modify the vxl source, should=20 I still have separate source trees for each build? I thought nothing=20 gets changed in the source tree by the build process... > By the way, I'm not sure whether you are implying this in your email,=20 but I would not recommend doing development or making changes inside=20 your dashboard build source trees. Again, I'm not modifying the vxl source tree. My source code uses vxl in=20 a separate tree structure. However, this is something I'll keep in mind=20 since I do look forward to adding my "two cents" to the vxl effort. Thanks again, Miguel Wheeler, Frederick W (Research) wrote: > Miguel, >=20 > It would be great to have additional Dart builds for Visual Studio 7 .N= ET. There is a Win2k_=ADmsvc-7.=AD0_=ADRelease build, but there were a lo= t of=20 changes between 7.0 and 7.1. I'm not sure whether the WinXP-msvc7-Debug=20 build is 7.0 or 7.1. It is probably 7.1, but the more the merrier,=20 especially if one of your nightly builds is a Release build. So thanks=20 for giving this a go. >=20 > Why not just do your Debug and Release builds in separate build trees? = This will not use a significant amount of additional space, since the bu= lk of the space will be used by the objects and libraries, not the direct= ory structure. Cmake will more readily handle that setup and that is wha= t most people do. It is also easier to keep a separate source tree for e= ach dashboard build. The local space required for a source tree is much = less than that of the build tree, and don't worry about the CVS traffic o= n the server. Again this is what most people do and is what cmake most r= eadily supports. Some have tried to get multiple nightly builds to work = off the same source tree. At best it is difficult. I think it is not wo= rth the effort. >=20 > By the way, I'm not sure whether you are implying this in your email, b= ut I would not recommend doing development or making changes inside your = dashboard build source trees. Local changes will affect the dashboard, w= hich is not too big a deal since local changes will also be shown on the = dashboard. CVS update conflicts can be a bigger headache. >=20 > Fred Wheeler >=20 >=20 >>-----Original Message----- >>From: vxl...@li... >>[mailto:vxl...@li...]On Behalf Of Miguel A. >>Figueroa-Villanueva >>Sent: Monday, October 03, 2005 4:34 AM >>To: vxl...@li... >>Subject: [Vxl-users] problems submitting nightly build with ctest for >>debug/release >> >> >>Hello, >> >>Please let me know if I should post the question in the CMake=20 >>lists and=20 >>not here. >> >>I'm not sure if there is too much interest in having another nightly=20 >>build for a: >> >>- OS: WinXP Pro with SP2 >>- Compiler: Visual Studio 7 .NET 2003 >>- Machine: AMD Athlon XP 2400+ 2GHz 1GB DDR RAM >>- cmake and vxl updated daily from cvs >> >>But since I am trying to get into the habit of keeping my vxl build=20 >>up-to-date automatically, I figured it wouldn't be much more work to=20 >>test and submit the build. BTW, I'm running everything from=20 >>the cygwin=20 >>bash shell, and using cygwin tools except for the Compiler, and CMake=20 >>(which is built with MS VS 7.1). >> >>I have successfully built vxl and submitted it as Nightly and=20 >>Experimental a few times. And I built the debug and release versions=20 >>using something like: >> >>- devenv.com /build Release(or Debug) /project ALL_BUILD >> >>The problem that I am having is that I can't get them built=20 >>using ctest.=20 >>That is build both the release and debug configurations in the same=20 >>binary tree (I have source and binary trees separate) and=20 >>submit results=20 >>for both of them together or separately. I definitely want to=20 >>keep both=20 >>configurations in the same tree and I can't afford to erase=20 >>everything=20 >>daily. >> >>I have tried several things, but basically this is what I thought I=20 >>should be doing (after reading several documentation pages,=20 >>cmake book,=20 >>and searching everywhere I could think): >> >> "${MYCTEST} -D NightlyStart" >> "${MYCTEST} -D NightlyUpdate" >> "${MYCTEST} -C Release -D NightlyConfigure" >> "${MYCTEST} -C Release -D NightlyBuild" >> "${MYCTEST} -C Release -D NightlyTest" >> "${MYCTEST} -C Debug -D NightlyConfigure" >> "${MYCTEST} -C Debug -D NightlyBuild" >> "${MYCTEST} -C Debug -D NightlyTest" >> "${MYCTEST} -D NightlySubmit" >> >>where ${MYCTEST} is set to the ctest program path. >> >>This, however, builds the release version in lib/release, but doesn't=20 >>build build lib/debug files. I think it might have to do with=20 >>clearing=20 >>some files... >> >>Any insight on how to solve this issue will be greatly appreciated. >> >>Thanks, Miguel >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Power Architecture Resource Center: Free content, downloads,=20 >>discussions, >>and more. http://solutions.newsforge.com/ibmarch.tmpl >>_______________________________________________ >>Vxl-users mailing list >>Vxl...@li... >>https://lists.sourceforge.net/lists/listinfo/vxl-users >> |