[Insight-developers] proposal: remove the gdcm build options from ITK
Mark Roden
mmroden at gmail.com
Sun Mar 13 09:35:03 EDT 2011
Hi Alex,
Before we leave the subject, I've done some more investigating into
the gdcm tests. I wiped everything (rm -rf *) and restarted with a
clone from the repository.
First, should it be possible to build itk without building
ITKGroup-Core? I'd think that the core group should always be built,
and any user choosing not to do so is just shooting themselves in the
foot. You can just build testing, but that leads to my second point:
the tests aren't (yet) organized into the proper submodules.
Second, when I build just ITKGroup-Core and ITKGroup-IO, the gdcm
tests aren't present, but the gdcm build options show up. That
suggests to me that the gdcm tests have been moved to another module.
If I include Utilities, the gdcm tests are still not included. Same
with Bridge. Using Luis' grep -r -n trick, I find that the nonunit
module has the gdcm tests.
This is a non-obvious location, in my mind. I would have each module
be able to build its own tests, and the test driver be part of the
core (which, as I suggested earlier, should never not be included).
That way, when I build gdcm, I also build relevant tests. I don't
have to go ahead and build 'nonunit' (I don't even know what that
means, especially since these look to be unit tests). It also means
that 'testing' would mean turning on the tests for each module, rather
than what happens now, where just having 'testing' enabled 129 tests
starting with 'itk', including:
ITK-Common = 6.09 sec
ITK-IO-BMP = 0.23 sec
ITK-IO-Base = 0.13 sec
ITK-IO-JPEG = 0.17 sec
ITK-IO-Meta = 0.15 sec
ITK-IO-PNG = 0.16 sec
ITK-IO-TIFF = 0.33 sec
ITK-IO-VTK = 0.17 sec
Shouldn't the common tests only get made when Core gets compiled, and
the IO tests when the IO module gets compiled? Why have tests for
modules that aren't otherwise made?
In the meantime, I'll go ahead and use nonunit to get the gdcm tests,
but it does seem like this arrangement should change.
Working on the compilation against system gdcm now....
Mark
On Sat, Mar 12, 2011 at 8:46 PM, Alexandre GOUAILLARD
<agouaillard at gmail.com> wrote:
> hi mark,
>
> the minimum to make accessible from gdcm to ITK is the work on
> streaming, RT and the network (pacs support). My understanding is that
> the ITK layer for streaming is here, but not for the network. The
> design of the ITK layer for network should be done in collaboration
> with the mayo clinic team you met during last meeting in Boston.
>
> Also the roadmap should be:
> - develop the feature in gdcm [DONE]
> - compile ITK against system-gdcm
> - develop the ITK layer
> - merge gdcm in ITK
>
> I'm not confident the last two points should be done in this order.
>
> Maybe the gdcm community care to advice on this point either?
>
> alex.
>
>
> On Sun, Mar 13, 2011 at 12:21 PM, Mark Roden <mmroden at gmail.com> wrote:
>> Well, the fix may be there in the repository, but when I run:
>>
>> Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R itkGDCM
>> Test project /Users/mmroden/Documents/src/itk/itk-build-unix
>> No tests were found!!!
>>
>> Or with just gdcm:
>> Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R GDCM
>> Test project /Users/mmroden/Documents/src/itk/itk-build-unix
>> No tests were found!!!
>>
>> This is after turning everything on in CMake syncing 2 days ago. I
>> then synced 20 minutes ago:
>>
>> Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R GDCM
>> Test project /Users/mmroden/Documents/src/itk/itk-build-unix
>> Start 645: itkGDCMImageIOTest1
>> 1/8 Test #645: itkGDCMImageIOTest1 .................. Passed 1.30 sec
>> Start 646: itkGDCMImageIOTest2
>> 2/8 Test #646: itkGDCMImageIOTest2 .................. Passed 0.31 sec
>> Start 647: itkGDCMImageIOTest3
>> 3/8 Test #647: itkGDCMImageIOTest3 .................. Passed 0.19 sec
>> Start 648: itkGDCMImageIOTest4
>> 4/8 Test #648: itkGDCMImageIOTest4 .................. Passed 0.16 sec
>> Start 649: itkGDCMImageIOTest5
>> 5/8 Test #649: itkGDCMImageIOTest5 .................. Passed 0.30 sec
>> Start 650: itkGDCMSeriesReadImageWrite
>> 6/8 Test #650: itkGDCMSeriesReadImageWrite .......... Passed 0.26 sec
>> Start 651: itkGDCMSeriesStreamReadImageWrite1
>> 7/8 Test #651: itkGDCMSeriesStreamReadImageWrite1 ... Passed 0.19 sec
>> Start 652: itkGDCMSeriesStreamReadImageWrite2
>> 8/8 Test #652: itkGDCMSeriesStreamReadImageWrite2 ... Passed 0.19 sec
>>
>> 100% tests passed, 0 tests failed out of 8
>>
>> Label Time Summary:
>> ITK-IntegratedTest = 2.90 sec
>>
>> Total Test time (real) = 6.38 sec
>>
>> So either I didn't build everything right the first time, or I didn't
>> have the gdcm tests.
>>
>> I think that these tests only cover a subset of gdcm functionality;
>> the question is, what kind of functionality are we going to need to
>> add in?
>>
>> Mark
>>
>>
>>
>> On Sat, Mar 12, 2011 at 1:01 PM, Alexandre GOUAILLARD
>> <agouaillard at gmail.com> wrote:
>>> mark,
>>>
>>> The latest itk v4 pulled form git has the itkGDCM tests (see below).
>>> You mentioned that those tests were not present since modularization,
>>> but I find trace of a feb 9th merge of a feb 5th commit that seems to
>>> indicate the support was taken care of:
>>>
>>> Merge topic 'ModularizationFixingGDCMTestDriver'
>>> 55c0f87 ENH: Use IO test driver for GDCM IO tests.
>>>
>>> I also confirmed that the gdcm cmake variables you mentioned (as well
>>> as direct gdcm wrapping variables) where present before and are still
>>> present. I did not turn them ON to test (yet).
>>>
>>> I agree with you that if they are of no use for ITK, they should not
>>> be visible when using the itk copy of gdcm.
>>>
>>> Perhaps the gdcm community would like to comment on this?
>>>
>>> alex.
>>>
>>> ld: warning: duplicate dylib ../../../../lib/libITK-Path-4.0.1.dylib
>>> ld: warning: duplicate dylib ../../../../lib/libITK-Transform-4.0.1.dylib
>>> ld: warning: duplicate dylib ../../../../lib/libITK-Statistics-4.0.1.dylib
>>> ld: warning: duplicate dylib ../../../../lib/libITK-Common-4.0.1.dylib
>>> [100%] Built target ITK-IntegratedTestTestDriver
>>> NB8086:BUILD-DEBUG-64 gouaillarda$ ctest -R GDCM
>>> Test project /Users/gouaillarda/DEVEL/GITROOT/ITK/BUILD-DEBUG-64
>>> Start 645: itkGDCMImageIOTest1
>>> 1/8 Test #645: itkGDCMImageIOTest1 .................. Passed 2.45 sec
>>> Start 646: itkGDCMImageIOTest2
>>> 2/8 Test #646: itkGDCMImageIOTest2 .................. Passed 0.38 sec
>>> Start 647: itkGDCMImageIOTest3
>>> 3/8 Test #647: itkGDCMImageIOTest3 .................. Passed 0.28 sec
>>> Start 648: itkGDCMImageIOTest4
>>> 4/8 Test #648: itkGDCMImageIOTest4 .................. Passed 0.20 sec
>>> Start 649: itkGDCMImageIOTest5
>>> 5/8 Test #649: itkGDCMImageIOTest5 .................. Passed 0.37 sec
>>> Start 650: itkGDCMSeriesReadImageWrite
>>> 6/8 Test #650: itkGDCMSeriesReadImageWrite .......... Passed 0.33 sec
>>> Start 651: itkGDCMSeriesStreamReadImageWrite1
>>> 7/8 Test #651: itkGDCMSeriesStreamReadImageWrite1 ... Passed 0.28 sec
>>> Start 652: itkGDCMSeriesStreamReadImageWrite2
>>> 8/8 Test #652: itkGDCMSeriesStreamReadImageWrite2 ... Passed 0.25 sec
>>>
>>> 100% tests passed, 0 tests failed out of 8
>>>
>>> Label Time Summary:
>>> ITK-IntegratedTest = 4.55 sec
>>>
>>> Total Test time (real) = 6.32 sec
>>> NB8086:BUILD-DEBUG-64 gouaillarda$
>>>
>>>
>>>
>>> On Sun, Mar 13, 2011 at 2:13 AM, Mark Roden <mmroden at gmail.com> wrote:
>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the Insight-developers
mailing list