The usual method of doing things would be IF(ITK_USE_SYSTEM_DCMTK) find_package(DCMTK REQUIRED) # yadda yadda. ENDIF()
This would fail if DCMTK_DIR is not defined -- assuming of course DCMTK isn't installed in the standard paths. -- Kent Williams [email protected] On 5/29/12 1:34 PM, "Jean-Christophe Fillion-Robin" <[email protected]> wrote: > >On Tue, May 29, 2012 at 11:55 AM, Williams, Norman K ><[email protected]> wrote: > > >Jean-Christophe, it seems like what you're saying is that you wish >DCMTK_DIR, if defined, to in essence, force ITK_USE_SYSTEM_DCMTK. That's >fine, and looking how other external packages are dealt with -- FFTW being >the prime example -- that's how it would work. > > > >If passing both -DITK_USE_SYSTEM_DCMTK:BOOL=ON and >-DDCMTK_DIR:PATH=/path/to/my/dcmtk when configuring ITK works as >expected, I guess that should be enough from Slicer perspective. > >Thanks >Jc > > > > >Bill, I think that the goal, as indicated by Terry Yu, is that GDCM will >be deprecated, so the DCMTK reader will be the one true way to deal with >DICOM. This could be a problem for programs that have used GDCMImageIO >explicitly -- or used GDCM calls directly, but I think most people were >cured of that tendency when ITK went from GDCM1 to GDCM2, which broke >anything that used GDCM in a non-trivial fashion. > >I think I see my way clear to make DCMTK work as well -- or probably >better -- than GDCM as a DICOM reader. I need to focus on that and >produce a Gerrit patch. There are a ton of peripheral issues around >DICOM reading that will take longer to iron out. > >The fact of the matter is that DICOM is squirrelly enough to make it >impossible to use transparently with the existing ImageIO framework. For >one thing, the ImageFileReader/Writer really don't want to deal with >directories as image paths, so any program who wants to use ITK for Image >IO has to have infrastructure around ImageIO to sniff for the DICOM case >and do it differently than every other file format. > >Plus DICOM is potentially quite a lot more than just files in a file >system, and ITK has never dealt with the rest of DICOM at all. Slicer4 >has some support for network DICOM stuff, but they're using DCMTK directly >to handle that case. > >On 5/29/12 10:28 AM, "Bill Lorensen" <[email protected]> wrote: > >>If you treat dcmtk as we treat vtk then you will not need a >>ITK_USE_SYSTEM_DCMTK. > > > > >________________________________ >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. > > >________________________________ > > > > > > > > >-- >+1 919 869 8849 > ________________________________ 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
