[Insight-developers] redefinition of HAVE_SYS_TYPES_H and HAVE_STDINT_H

Tue Nov 24 09:12:06 EST 2009

Hi Brad,

No warning anymore on my side.
Thanks a lot!

Gaëtan

Le 23 nov. 09 à 19:46, Bradley Lowekamp a écrit :

> *sigh* This cmake configuration has been surprisingly tricky and  
> error prone.
>
> I have since patched itkConfigure.h.in with what should be a working  
> version now.
>
>
> 1)
>
> That is a very good find! Thank you! I would not be certain moving  
> the CONFIGURE_FILE would be free from side effects, better I just  
> move the fenv.h check.
>
> 2)
>
> My concern still stands with the #ifundef guarding. If another  
> config header has a define for HAVE_INCLUDE_H but is include after  
> our header, we will have redefinitions and generate a compiler  
> warning. I think adding the ITK_ prefix is safest.
>
> http://www.itk.org/cgi-bin/viewcvs.cgi/itkConfigure.h.in?root=Insight&r1=1.36&r2=1.37&sortby=date
>
>
>
> Brad
>
> On Nov 23, 2009, at 1:25 PM, Tom Vercauteren wrote:
>
>> Hi Brad,
>>
>> I just tried to use some of your recent changes (to move on with the
>> unicode filename patch) and found two issues.
>>
>> 1) The availability of fenv.h is the last thing that is done in the
>> main CMakeLists.h
>> http://www.itk.org/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=Insight&r1=1.355&r2=1.356&sortby=date
>> However HAVE_FENV_H is used by itkConfigure.h.in
>> http://www.itk.org/cgi-bin/viewcvs.cgi/itkConfigure.h.in?root=Insight&r1=1.35&r2=1.36&sortby=date
>>
>> This means that when starting from a clean build tree
>>  CONFIGURE_FILE(${ITK_SOURCE_DIR}/itkConfigure.h.in
>>    ${ITK_BINARY_DIR}/itkConfigure.h)
>> will be called before checking for HAVE_FENV_H and ITK_HAVE_FENV_H  
>> will be false
>>
>> The fix seems easy:
>>  CONFIGURE_FILE(${ITK_SOURCE_DIR}/itkConfigure.h.in
>>    ${ITK_BINARY_DIR}/itkConfigure.h)
>> should be the last thing done in the main CMakeLists.txt, right?
>>
>>
>>
>> 2) It looks like the following patch is wrong
>> http://www.itk.org/cgi-bin/viewcvs.cgi/itkConfigure.h.in?root=Insight&r1=1.35&r2=1.36&sortby=date
>>
>> I don't get how this kind of code may work:
>>  #if @HAVE_FENV_H@
>>  #define ITK_HAVE_FENV_H
>>  #endif /* @HAVE_FENV_H@ */
>>
>> What I just tried (with a cvs version of cmake) is to add this right
>> before the previous call to CONFIGURE_FILE
>>  CHECK_INCLUDE_FILES("unistd.h" HAVE_UNISTD_H)
>>  CHECK_INCLUDE_FILES("windows.h" HAVE_WINDOWS_H)
>> and
>>  #if @HAVE_UNISTD_H@
>>  #define ITK_HAVE_UNISTD_H
>>  #endif /* @HAVE_UNISTD_H@ */
>>
>>  #ifdef @HAVE_WINDOWS_H@
>>  #define ITK_HAVE_WINDOWS_H
>>  #endif /* @HAVE_WINDOWS_H@ */
>>
>>
>> Looking at the generated itkConfigure.h, I get (on linux)
>>  #if 1
>>  #define ITK_HAVE_UNISTD_H
>>  #endif /* 1 */
>>
>>  #if
>>  #define ITK_HAVE_WINDOWS_H
>>  #endif /*  */
>>
>> This leads to a gcc error:
>>  error: #if with no expression
>>
>>
>> Reverting to cmakedefine works fine in this case.
>>
>> I am not sure how to ideally achieve your goal but something like
>>  #ifndef HAVE_UNISTD_H
>>  #cmakedefine HAVE_UNISTD_H
>>  #endif
>>  #ifdef HAVE_UNISTD_H
>>  #define ITK_HAVE_UNISTD_H
>>  #endif
>> seems to do the trick (even thought it is quite ugly).
>>
>>
>> Regards,
>> Tom
>>
>>
>> On Mon, Nov 23, 2009 at 15:41, Bradley Lowekamp <blowekamp at mail.nih.gov 
>> > wrote:
>>> The complication is that the CHECK_TYPE_SIZE macro implicitly  
>>> searches for
>>> some headers. So for this particular header there is no  
>>> CHECK_INCLUDE_FILES
>>> directly called by Insight/CMake.
>>> I am trying my approach now, and hopefully will have a commit to  
>>> remove
>>> those pesky warning shortly.
>>> Brad
>>> On Nov 23, 2009, at 3:43 AM, Gaëtan Lehmann wrote:
>>>
>>> Le 20 nov. 09 à 14:01, Bradley Lowekamp a écrit :
>>>
>>> But if  itkConfigure.h is included before phython then it wont  
>>> work, because
>>> phython is not ifndef. I think what may be needed is similar to the
>>> following:
>>>
>>> #if @HAVE_STDINT_H@
>>>
>>> #define ITK_HAVE_STDINT_H
>>>
>>> #endif
>>>
>>> I'd need to look at what the value of @HAVE_STDINT_H@ would be. By  
>>> doing
>>> this we can use the standard naming inside CMAKE, and convert it  
>>> to our own
>>> in the ITK code.
>>>
>>>
>>> Why not using directly the ITK_ prefix in cmake?
>>> The chance to have a collision in that case seems quite low.
>>>
>>> Am I missing something?
>>>
>>> Gaëtan
>>>
>>> --
>>> Gaëtan Lehmann
>>> Biologie du Développement et de la Reproduction
>>> INRA de Jouy-en-Josas (France)
>>> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>>> http://voxel.jouy.inra.fr  http://www.itk.org
>>> http://www.mandriva.org  http://www.bepo.fr
>>>
>>>
>>> ========================================================
>>>
>>> Bradley Lowekamp
>>>
>>> Lockheed Martin Contractor for
>>>
>>> Office of High Performance Computing and Communications
>>>
>>> National Library of Medicine
>>>
>>> blowekamp at mail.nih.gov
>>>
>>>
>>> _______________________________________________
>>> 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.html
>>>
>>> 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
>>>
>>>
>
> ========================================================
> Bradley Lowekamp
> Lockheed Martin Contractor for
> Office of High Performance Computing and Communications
> National Library of Medicine
> blowekamp at mail.nih.gov
>
>

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20091124/283d2215/attachment.pgp>