[Insight-developers] proposal: remove the gdcm build options from ITK

[Mark Roden]

I assumed as much, but I wanted to be sure.  There could have been the
intent to push all gdcm tests into gdcm proper.  And as I said, there
are none of the standard gdcm tests in itk now, nor were they there
prior to the merge, so if that was the intent, I just need to know so
that I can put them there.

Mark

On Sat, Mar 12, 2011 at 9:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I think the itkGDCM tests should definitely stay. I assume that their
> absence after modularization is not intentional.
>
> Bill
>
> On Sat, Mar 12, 2011 at 10:29 AM, Alexandre GOUAILLARD
> <agouaillard at gmail.com> wrote:
>> hi
>>
>> On Sat, Mar 12, 2011 at 2:55 PM, Mark Roden <mmroden at gmail.com> wrote:
>>> Hi,
>>>
>>> Previously, there were itk-gdcm specific tests, that could be run by typing
>>>
>>> ctest -R itkGDCM
>>>
>>> Those tests are no longer present since modularization.  I do not know
>>> if they have been removed because they don't match the expectations of
>>> the new scheme, or as an oversight, or if the gdcm_build_tests cmake
>>> flag was supposed to cover it.  I'm putting this discussion on the
>>> insight developers list as a result, so that perhaps I can get some
>>> feedback on that.
>>
>> I'm checking that right now.
>>
>>>
>>> Personally, I think that we should just have the itk gdcm tests back,
>>> and not have the same coverage as the rest of gdcm.  ITK devs, at
>>> least for the moment, don't need a complete tag editing solution, they
>>> need to be able to read and write various forms of image data.  I'm
>>> fairly certain that the previous test suite covered those cases.
>>>
>>
>> We have to be positive.
>>
>>> The testing data size is a few megs, so not a big deal, and it's
>>> retrieved through a git submodule init call in the gdcm root
>>> directory.  That is a bit of a pain for deployment purposes, because
>>> it means that any user who wants to use gdcm has to get a particular
>>> set of images for testing, and they have to use a series of
>>> non-obvious steps to get those images and set up the testing directory
>>> (which is, as I said, currently blank).  I suppose that could be done
>>> through the setupfordevelopment script, but that seems like overkill,
>>> especially if the older itkgdcm tests did the job.
>>>
>>
>> That sounds good, the actual testing/data is also retrieved thourgh a
>> git submodule mechanism, so I guess, if we were to decide to take in
>> the gdcm tests, there is no show stopper. We need to investigate if
>> that s really what we want / need to do. i.e. we need to have a list
>> of gdcm features available in ITK proper.
>>
>> alex.
>>
>>> Mark
>>>
>>> On Fri, Mar 11, 2011 at 10:35 PM, Alex Gouaillard <agouaillard at gmail.com> wrote:
>>>> Hi mark.
>>>>
>>>>> it would be good to know how these tests worked in the
>>>>> past.
>>>>
>>>> Your job to find out.
>>>>
>>>> Then if those tests were not included, please answer the following questions first:
>>>> - are those testing gdcm features exposed in itk ? If not, no need in itk proper.
>>>> - what is the size of the testing data?
>>>> - how do you get the data? (cvs? Svn? Tarball?...)
>>>>
>>>> Gaetan, can you then advice on using external project Thingy from cmake 2.8 ?
>>>>
>>>>>
>>>>> Mark
>>>>>
>>>>> 2011/3/11 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>>>>>>
>>>>>> Le 12 mars 11 à 01:04, Mark Roden a écrit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> So I notice that under the new (and the old, incidentally) cmake
>>>>>>> options for itk, there are the four canonical gdcm options, namely:
>>>>>>>
>>>>>>> build_applications
>>>>>>> build_examples
>>>>>>> build_shared_libs
>>>>>>> build_testing
>>>>>>>
>>>>>>> However, since the gdcm stuff is supposed to be rolled in directly
>>>>>>> with ITK, these options don't make a whole lot of sense to me.
>>>>>>> Indeed, choosing build_testing as an option leads to cmake errors
>>>>>>> which, when solved, lead to many compilation errors when testing is
>>>>>>> turned on.
>>>>>>>
>>>>>>> I propose to remove these options from the build process entirely.
>>>>>>> The user isn't interested in gdcm per se, but in having dicom support
>>>>>>> in itk.  That means that these options are not useful to the user, and
>>>>>>> can only cause building problems.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Mark
>>>>>>
>>>>>>
>>>>>> Hi Mark,
>>>>>>
>>>>>> I'd keep the tests, and turn them on automatically when ITK's option
>>>>>> BUILD_TESTING is on. I don't think you will reimplement all the gdcm tests
>>>>>> in ITK, so it would be nice that gdcm can be tested on the user system with
>>>>>> the other ITK tests.
>>>>>> This wouldn't be the only case: VXL tests are run with the ITK tests for
>>>>>> example.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>> _______________________________________________
>> 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
>>
>