[Insight-developers] Why are FFTW CMake variables different?

Matt McCormick matt.mccormick at kitware.com
Wed Jan 2 11:11:48 EST 2013


On Wed, Dec 19, 2012 at 2:00 PM,  <M.Staring at lumc.nl> wrote:
> Should ITKV3_COMPATIBILITY then be renamed to ITK_V3_COMPATIBILITY ?

No, I think "ITKV3" is taken as one term as is "ITKV4".

Matt


>
> Marius
>
> -----Original Message-----
> From: insight-developers-bounces at itk.org [mailto:insight-developers-bounces at itk.org] On Behalf Of Bill Lorensen
> Sent: dinsdag 18 december 2012 19:22
> To: Matt McCormick
> Cc: <insight-developers at itk.org> Developers; Williams, Norman K
> Subject: Re: [Insight-developers] Why are FFTW CMake variables different?
>
> +1 to Matt's comments
>
>
> On Tue, Dec 18, 2012 at 12:56 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>> I agree that they should follow a consistent style, but an attempt at
>> backwards compatibility should be made.  Those variables are hard set
>> in many people's ExternalProject's, build scripts, etc.
>>
>> Matt
>>
>>
>> On Tue, Dec 18, 2012 at 4:25 PM, Williams, Norman K
>> <norman-k-williams at uiowa.edu> wrote:
>>>
>>> I think you're exactly right.  Those variables are named the way they
>>> are because when I chose those names USE_<something> names were all
>>> over the place. As we've all progressed as developers and refined the
>>> conventions used in ITK, things like that have gone away.
>>>
>>>
>>> I see no reason not to change this to make it consistent.  As far as
>>> 'backwards compatibility' -- we promise code compatibility not CMake
>>> compatibility.  Since FFTW is not on by default, someone has to go
>>> looking when they run CMake for the FFTW variables to turn on.
>>> They'll find them whether they're properly prefixed ITK_ or not.
>>>
>>> And that little snippet of CMake code is something I never thought about.
>>> CMake programming sure can be powerful.  At this point we could
>>> probably re-write ITK in CMake.
>>>
>>> On 12/18/12 9:38 AM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>>>
>>> >Hello,
>>> >
>>> >I was looking to pass some CMake variable from my SimpleITK
>>> >superbuild down to the ITK external project build. So I assembled a
>>> >list for cmake varaibles that began with "ITK_":
>>> >
>>> >get_cmake_property( _varNames VARIABLES )
>>> >
>>> >foreach (_varName ${_varNames})
>>> >  if(_varName MATCHES "^ITK_" )
>>> >    message( "Variable defined ${_varName}: ${${_varName}}")
>>> >    list(APPEND ITK_VARS ${_varName})
>>> >  endif()
>>> >endforeach()
>>> >
>>> >
>>> >And passed to those to my ITK external project. While these ITK
>>> >cmake variables are not defined in the top level, a user could base
>>> >say "-DITK_USE_SYSTEM_TIFF:BOOL=ON" to the top level superbuild, and
>>> >ITK would be configured and build with this user specified option.
>>> >(This will get a lot more interesting when enabling module could
>>> >also be passes.)
>>> >
>>> >Only problem is that the FFTW cmake variables don't match. These are
>>> >the ones I am talking about:
>>> >
>>> >USE_SYSTEM_FFTW
>>> >USE_FFTWD
>>> >USE_FFTWF
>>> >
>>> >I think that these variable should begin with ITK to match the reset
>>> >of the similar variable in ITK.
>>> >
>>> >Does anyone else have an opinion on this?
>>> >
>>> >
>>> >Thanks,
>>> >Brad
>>> >
>>> >_______________________________________________
>>> >Powered by www.kitware.com
>>> >
>>> >Visit other Kitware open-source projects at
>>> >http://www.kitware.com/opensource/opensource.html
>>> >
>>> >Kitware offers ITK Training Courses, for more information visit:
>>> >http://kitware.com/products/protraining.php
>>> >
>>> >Please keep messages on-topic and check the ITK FAQ at:
>>> >http://www.itk.org/Wiki/ITK_FAQ
>>> >
>>> >Follow this link to subscribe/unsubscribe:
>>> >http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>>>
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered
>>> by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>> confidential and may be legally privileged.  If you are not the
>>> intended recipient, you are hereby notified that any retention,
>>> dissemination, distribution, or copying of this communication is strictly prohibited.
>>> Please reply to the sender that you have received the message in
>>> error, then delete it.  Thank you.
>>> ________________________________
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers


More information about the Insight-developers mailing list