[Insight-developers] Updating two ITK CTest Scripts: Re: Thousands of warnings on cygwin/mingw builds

Bill Lorensen bill.lorensen at gmail.com
Fri Aug 14 13:18:59 EDT 2009


Also, my cygwin does not have these warnings.

Is there some difference between the two styles of ctest scripting?

We need to resolve this issue before our upcoming release.

Bill

On Thu, Aug 13, 2009 at 11:16 AM, Bill Lorensen<bill.lorensen at gmail.com> wrote:
> David,
>
> Here is my ctest script:
>
>  #
> # This is a recommended file for ITK dashboard submissions
> # The generated file will use the current settings in the CMakeCache.txt file
> # The file should be copied, edited if necessary and moved to another location
> #
> # This file was generated from
> # C:/lorensen/Projects/Insight/CMake/itkSampleBuildTest.cmake
> #
>
> ######################
> # Set the Dashboard to one of Nightly, Continuous or Experimental
> #
> SET(DASHBOARD Nightly)
> SET(DASHBOARD Continuous)
> SET(DASHBOARD Experimental)
>
> ######################
> # Set the Default Build Type to one of Release, Debug, RelWithDebInfo
> # or MinSizeRel
> #
> SET(DEFAULT_BUILD_TYPE "Debug")
> SET(DEFAULT_BUILD_TYPE "RelWithDebInfo")
> SET(DEFAULT_BUILD_TYPE "MinSizeRel")
> SET(DEFAULT_BUILD_TYPE "Release")
>
> IF("Release" STREQUAL "")
>  SET(BUILD_TYPE ${DEFAULT_BUILD_TYPE})
> ELSE("Release" STREQUAL "")
>  SET(BUILD_TYPE Release)
> ENDIF("Release" STREQUAL "")
>
>
> # These are the the locations of the source and binary directory
> SET(CTEST_SOURCE_DIRECTORY "C:/lorensen/Projects/Insight")
> SET(CTEST_BINARY_DIRECTORY "C:/lorensen/Projects/Insight-mingw")
>
> # The ctest command to use for running the dashboard
> SET(CTEST_COMMAND
>   "c:/Program Files/CMake 2.6/bin/cmake.exe -P
> \"${CTEST_BINARY_DIRECTORY}/CMake/RemoveTemporaryFiles.cmake\""
>   "c:/Program Files/CMake 2.6/bin/ctest.exe -D ${DASHBOARD} -A
> \"${CTEST_SCRIPT_DIRECTORY}/${CTEST_SCRIPT_NAME}\""
> )
>
> # CMake/RemoveTemporaryFiles.cmake must exist before the CTEST_COMMAND runs
> IF(NOT EXISTS ${CTEST_BINARY_DIRECTORY}/CMake/RemoveTemporaryFiles.cmake)
>  SET(CTEST_CMAKE_COMMAND "C:/Program Files/CMake 2.6/bin/cmake.exe")
> ENDIF(NOT EXISTS ${CTEST_BINARY_DIRECTORY}/CMake/RemoveTemporaryFiles.cmake)
>
> # CMakeCache.txt must exist before the CTEST_COMMAND runs
> IF(NOT EXISTS ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt)
>  SET(CTEST_CMAKE_COMMAND "C:/Program Files/CMake 2.6/bin/cmake.exe")
> ENDIF(NOT EXISTS ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt)
>
> # Specify how long to run the continuous in minutes
> IF(${DASHBOARD} STREQUAL "Continuous")
>  SET (CTEST_CONTINUOUS_DURATION 1080)
>  SET (CTEST_CONTINUOUS_MINIMUM_INTERVAL 15)
> ENDIF(${DASHBOARD} STREQUAL "Continuous")
>
> # Set defaults
> SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY FALSE)
> SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE FALSE)
>
> # For Nightly builds, this should be TRUE
> IF(${DASHBOARD} STREQUAL "Nightly")
>  SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)
> ELSE(${DASHBOARD} STREQUAL "Nightly")
>  SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY FALSE)
> ENDIF(${DASHBOARD} STREQUAL "Nightly")
>
> # For Continuous builds. this should be TRUE
> IF(${DASHBOARD} STREQUAL "Continuous")
>  SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE TRUE)
> ELSE(${DASHBOARD} STREQUAL "Continuous")
>  SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE FALSE)
> ENDIF(${DASHBOARD} STREQUAL "Continuous")
>
> # For Experimental builds, these should be FALSE
> IF(${DASHBOARD} STREQUAL "Experimental")
>  SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY FALSE)
>  SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE FALSE)
> ENDIF(${DASHBOARD} STREQUAL "Experimental")
>
> # This is the initial cache to use for the binary tree, be careful to escape
> # any quotes inside of this string if you use it
> SET (CTEST_INITIAL_CACHE "
> SITE:STRING=BillsLaptop
> BUILDNAME:STRING=Mingw-g++3.4
> CVSCOMMAND:FILEPATH=C:/Program Files/TortoiseCVS/cvs.exe
> CVS_UPDATE_OPTIONS:STRING=-d -A -P
>
> CMAKE_C_FLAGS_RELEASE:STRING=-Wno-uninitialized -O3 -DNDEBUG
> CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-Wno-uninitialized -O2 -g
> CMAKE_CXX_FLAGS_RELEASE:STRING=-Wno-uninitialized  -O3 -DNDEBUG
> CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-Wno-uninitialized -O2 -g
>
> TCL_TCLSH:FILEPATH=c:/tcl/bin/tclsh.exe
> CMAKE_BUILD_TOOL:INTERNAL=C:/msys/1.0/bin/make.exe
> CMAKE_MAKE_PROGRAM:FILEPATH=C:/msys/1.0/bin/make.exe
> CMAKE_GENERATOR:INTERNAL=MSYS Makefiles
> CMAKE_CXX_COMPILER:FILEPATH=c:/mingw/bin/g++.exe
> CMAKE_CXX_FLAGS:STRING=-Wshadow -Woverloaded-virtual
> CMAKE_C_COMPILER:FILEPATH=c:/MinGW/bin/gcc.exe
> CMAKE_C_FLAGS:STRING=
> CMAKE_CONFIGURATION_TYPES:STRING=${BUILD_TYPE}
> CMAKE_BUILD_TYPE:STRING=${BUILD_TYPE}
>
> BUILD_SHARED_LIBS:BOOL=ON
> BUILD_TESTING:BOOL=ON
> BUILD_EXAMPLES:BOOL=ON
>
> ITK_USE_PATENTED:BOOL=ON
> ITK_USE_REVIEW:BOOL=ON
> ITK_USE_REVIEW_STATISTICS:BOOL=ON
> ITK_USE_REGION_VALIDATION_IN_ITERATORS:BOOL=ON
> ITK_USE_CENTERED_PIXEL_COORDINATES_CONSISTENTLY:BOOL=ON
> ITK_USE_CONCEPT_CHECKING:BOOL=ON
> ITK_USE_OPTIMIZED_REGISTRATION_METHODS:BOOL=ON
> ITK_USE_ORIENTED_IMAGE_DIRECTION:BOOL=ON
> ITK_USE_DEPRECATED_LEVELSET_INTERPOLATION:BOOL=OFF
> ITK_USE_CONSOLIDATED_MORPHOLOGY:BOOL=ON
> ITK_USE_TEMPLATE_META_PROGRAMMING_LOOP_UNROLLING:BOOL=ON
> ITK_USE_TRANSFORM_IO_FACTORIES:BOOL=ON
> ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE:BOOL=ON
>
> ITK_USE_SYSTEM_GDCM:BOOL=OFF
> ITK_USE_SYSTEM_LIBXML2:BOOL=OFF
> ITK_USE_SYSTEM_PNG:BOOL=OFF
> ITK_USE_SYSTEM_TIFF:BOOL=OFF
> ITK_USE_SYSTEM_VXL:BOOL=OFF
> ITK_USE_SYSTEM_ZLIB:BOOL=OFF
>
> ITK_LEGACY_REMOVE:BOOL=ON
> ITK_LEGACY_SILENT:BOOL=ON
> GDCM_LEGACY_REMOVE:BOOL=ON
> GDCM_LEGACY_SILENT:BOOL=OFF
>
> ITK_USE_KWSTYLE:BOOL=ON
> KWSTYLE_EXECUTABLE:PATH=C:/lorensen/Projects/KWStyle-net/release/KWStyle.exe
> KWSTYLE_USE_VIM_FORMAT:BOOL=ON
> KWSTYLE_USE_MSVC_FORMAT:BOOL=
>
> ITK_CSWIG_JAVA:BOOL=OFF
> ITK_CSWIG_PYTHON:BOOL=OFF
> ITK_CSWIG_TCL:BOOL=OFF
> ITK_USE_LIBXML2:BOOL=OFF
> ITK_USE_MINC2:BOOL=OFF
>
> USE_WRAP_ITK:BOOL=OFF
> USE_FFTWD:BOOL=OFF
> USE_FFTWF:BOOL=OFF
> USE_SCSL:BOOL=OFF
> ")
>
> # Set any extra envionment variables here
> SET (CTEST_ENVIRONMENT
>  )
>
>
>
>
> On Thu, Aug 13, 2009 at 11:03 AM, David Cole<david.cole at kitware.com> wrote:
>> What else is different between your build and ours?
>>
>>
>> On Thu, Aug 13, 2009 at 8:28 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>>>
>>> Yes, my build has shared libs on.Recently Brad made changes to
>>> properly make shaed libs with mingw:
>>>
>>> http://public.kitware.com/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=Insight&r1=1.344&r2=1.345
>>>
>>> The comments onmhis checkin:
>>> ENH: Build shared libs with GNU on Windows
>>>
>>> The GNU toolchain on windows supports automatic dllexport of all symbols
>>> in a library.  This simulates the everything-is-public methodology of
>>> UNIX systems.  Therefore we can build vxl and ITK libraries as shared
>>> even though the sources do not all contain export macro markup.
>>>
>>> Bill
>>>
>>> On Thu, Aug 13, 2009 at 7:17 AM, David Cole<david.cole at kitware.com> wrote:
>>> > These warnings
>>> > ("c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
>>> > warning: auto-importing has been activated without --enable-auto-import
>>> > specified on the command line.") will only show up when it is a
>>> > BUILD_SHARED_LIBS build.
>>> >
>>> > Does your mingw build have BUILD_SHARED_LIBS ON?
>>> >
>>> >
>>> > On Thu, Aug 13, 2009 at 12:20 AM, Bill Lorensen
>>> > <bill.lorensen at gmail.com>
>>> > wrote:
>>> >>
>>> >> Thousands are gone, but about 90 are left. I don't see these warnings
>>> >> on by mingw builds. I use the old ctest scripting, but I'm not sure if
>>> >> that makes any difference.
>>> >>
>>> >> http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=400576
>>> >>
>>> >> The cygwin build is also showing a bunch:
>>> >> http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=400477
>>> >>
>>> >> Bill
>>> >>
>>> >> On Wed, Aug 12, 2009 at 12:26 PM, Dave
>>> >> Partyka<dave.partyka at kitware.com>
>>> >> wrote:
>>> >> > It is up and running and appears to be performing ITK tests at the
>>> >> > moment.
>>> >> > What I don't like about this machine is that it is so slow that it
>>> >> > takes
>>> >> > all
>>> >> > day long to finish the nightly dashboards that it performs. When I
>>> >> > first
>>> >> > started looking at these dashboards I disabled things such as tcl
>>> >> > wrapping
>>> >> > and switched build to shared libraries, release mode builds in the
>>> >> > hope
>>> >> > of
>>> >> > speeding things up. These changes did help a little but still this
>>> >> > machine
>>> >> > is just plain old and overloaded.
>>> >> > VTK Cygwin
>>> >> > ITK Cygwin
>>> >> > VTK Mingw
>>> >> > ITK Mingw
>>> >> >
>>> >> > On Wed, Aug 12, 2009 at 12:21 PM, Luis Ibanez
>>> >> > <luis.ibanez at kitware.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Dave(s)
>>> >> >>
>>> >> >> Thanks for looking at these changes.
>>> >> >>
>>> >> >>
>>> >> >> BTW:
>>> >> >> Dash14  didn't submit yesterday and has not submitted today.
>>> >> >>
>>> >> >> On Monday it submitted (to ITK) at 4:55 am..
>>> >> >>
>>> >> >>
>>> >> >> In not getting any reply when I ping and ssh to dash14.
>>> >> >>
>>> >> >> I'm wondering if the machine is off...
>>> >> >>
>>> >> >> Do you know where this machine is physically located ?
>>> >> >> Could you take a look ?
>>> >> >>
>>> >> >>
>>> >> >>    Thanks
>>> >> >>
>>> >> >>
>>> >> >>          Luis
>>> >> >>
>>> >> >>
>>> >> >> ---------------------------
>>> >> >> On Wed, Aug 12, 2009 at 11:58 AM, Dave Partyka
>>> >> >> <dave.partyka at kitware.com>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Argh yes, If something goes a muck with a dashboard let me know as
>>> >> >>> part
>>> >> >>> of your first line of defense. It is likely something that I may
>>> >> >>> have
>>> >> >>> changed. Especially regarding new style scripts.
>>> >> >>>
>>> >> >>> On Wed, Aug 12, 2009 at 11:36 AM, David Cole
>>> >> >>> <david.cole at kitware.com>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Looping in party dave since he was probably the one who converted
>>> >> >>>> them...
>>> >> >>>> (Dave, this is just FYI -- sounds like Luis changed the scripts
>>> >> >>>> already...)
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Tue, Aug 11, 2009 at 8:11 PM, Luis Ibanez
>>> >> >>>> <luis.ibanez at kitware.com>
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> Hi Bill,
>>> >> >>>>>
>>> >> >>>>> Thanks for the fix, and for the remainder.
>>> >> >>>>>
>>> >> >>>>> I just committed the changes to the scripts:
>>> >> >>>>>
>>> >> >>>>> dash14_itk_cygwin.cmake
>>> >> >>>>> dash14_itk_mingw.cmake
>>> >> >>>>>
>>> >> >>>>> This should help clean up tomorrow's Dashboard,
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>>  Thanks
>>> >> >>>>>
>>> >> >>>>>      Luis
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> -----------------------------------
>>> >> >>>>> On Tue, Aug 11, 2009 at 7:43 PM, Bill Lorensen
>>> >> >>>>> <bill.lorensen at gmail.com> wrote:
>>> >> >>>>>>
>>> >> >>>>>> Reminder
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> ---------- Forwarded message ----------
>>> >> >>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>> >> >>>>>> Date: Sun, Aug 9, 2009 at 10:30 AM
>>> >> >>>>>> Subject: Thousands of warnings on cygwin/mingw builds
>>> >> >>>>>> To: Luis Ibanez <luis.ibanez at kitware.com>
>>> >> >>>>>> Cc: Insight Developers <insight-developers at itk.org>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> The cygwin and mingw builds on dash14.kitware have been
>>> >> >>>>>> generating
>>> >> >>>>>> 1000's of warnings for some time now (since 6/14 I think). I
>>> >> >>>>>> suspect
>>> >> >>>>>> that the nightlies were converted over to use the new ctest
>>> >> >>>>>> scripting.
>>> >> >>>>>> Prior to that the builds were warning free.
>>> >> >>>>>>
>>> >> >>>>>> Can you add to the cygwin and mingw ctest scripts:
>>> >> >>>>>> CMAKE_C_FLAGS_RELEASE:STRING=-Wno-uninitialized -O3 -DNDEBUG
>>> >> >>>>>> CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-Wno-uninitialized -O2 -g
>>> >> >>>>>> CMAKE_CXX_FLAGS_RELEASE:STRING=-Wno-uninitialized  -O3 -DNDEBUG
>>> >> >>>>>> CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-Wno-uninitialized -O2 -g
>>> >> >>>>>>
>>> >> >>>>>> Bill
>>> >> >>>>>
>>> >> >>>>
>>> >> >>>
>>> >> >>
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>


More information about the Insight-developers mailing list