Ya, unfortunatly I don't have the specific case that was failing anymore... it's probably because I've been using the same build output since 2.8.6 and just keep updating cmake... last couple versions have actually gone smoothly
On Fri, Aug 10, 2012 at 4:21 AM, David Cole <[email protected]> wrote: > Can you try again with a nightly build of CMake? > > There's a change that we did not take that *is* in the nightly build, > but is not in the 2.8.9 release. I'd like to know if that change is > responsible for this behavior. > > We were uncertain of this commit [ > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e16f58ddd6aea9bebc6b4a914eed54cf7517ff61 > ] ... so it did not go into the 2.8.9 release. > > > Thx, > David > > > On Thu, Aug 9, 2012 at 7:33 PM, J Decker <[email protected]> wrote: >> After considering this a bit more I went to this >> C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES directory adn removed >> Build*. and then everything built correctly. And BuildXXXXX did not >> come back. So maybe i've been changing cmake versions too much.... >> going to grab the 2.8.9 now anway. >> >> On Thu, Aug 9, 2012 at 4:27 PM, J Decker <[email protected]> wrote: >>> I'm having a little difficulty figuring out why this is not building >>> my projects using visual studio/msbuild. Basically all I get is >>> "========== Build: 0 succeeded, 0 failed, 24 up-to-date, 0 skipped >>> ==========" >>> >>> I've used MSBuild with /v:diag set and in the huge log that that >>> generates.... >>> >>> Outputs for >>> C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\D460CDD940FC411117A7C12689E8CBDF\BUILDCORE.RULE|M:\ALTANIK\CMAKE_ALL\CMAKELISTS.TXT: >>> (TaskId:43) >>> C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\GENERATE.STAMP >>> (TaskId:43) >>> C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\BUILDCORE (TaskId:43) >>> All outputs are up-to-date. (TaskId:43) >>> >>> How do I make sure that 'add_custom_target' is built? and I shouldn't >>> have to ask that because the docs say.... >>> >>> "Adds a target with the given name that executes the given commands. >>> The target has no output file and is ALWAYS CONSIDERED OUT OF DATE >>> even if the commands try to create a file with the name of the >>> target." >>> >>> >>> >>> >>> macro( BuildProject PROJECT SOLUTION PROJECT_SOURCE INSTALL_RESULT ) >>> #... >>> add_custom_target( Build${PROJECT} ALL >>> COMMAND cmake -G "${CMAKE_GENERATOR}" ${PROJECT_SOURCE} >>> -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} >>> -DCMAKE_INSTALL_PREFIX=${INSTALL} ${ARGN} >>> COMMAND ${BUILD_COMMAND} >>> WORKING_DIRECTORY ${BUILD} >>> ${ADD_SOURCES} >>> ) >>> #... >>> endmacro() >>> >>> ADD_SOURCES is the .SLN filename >>> BUILD is where it's building >>> BUILD_COMMAND was retreived using build_command() >>> >>> and occasionally do ADD_CUSTOM_COMMAND( target Build${PROJECT} ... >>> some other commands... ) >>> >>> >>> on watcom, mingw, and usually visual studio, the cmake lists that uses >>> this macro basically ends up running cmake and an approprite build >>> command for each project... >>> >>> I have a bunch fo project build targets, and have added dependencies >>> to most of that like 'add_dependencies( ${LAST_TARGET} Buildcore )' >>> so Buildcore will get built first... last_target is set by the >>> macro... yadda yadda. >>> >>> All of that works. >>> >>> But today, and some time last month a bit... >> -- >> >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
