From pieper at ibility.net Sun Nov 3 15:54:30 2013 From: pieper at ibility.net (Steve Pieper) Date: Sun, 3 Nov 2013 10:54:30 -0500 Subject: [Ctk-developers] hackfest planning Message-ID: Hi CTKers - It's almost time for the hacking to begin in London! I'm not sure of other people's schedules, but I will arrive in London in the morning and should be at UCL by early afternoon. See some of you in person, and some by hangout before long, -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.clarkson at ucl.ac.uk Sun Nov 3 17:32:12 2013 From: m.clarkson at ucl.ac.uk (Clarkson, Matt) Date: Sun, 3 Nov 2013 17:32:12 +0000 Subject: [Ctk-developers] Hackfest Start Time Message-ID: <7442F95C-30FE-441D-BB01-8905576F3231@live.ucl.ac.uk> Hi everyone attending the London Hackfest. People should arrive at the "Engineering Front Building", and refer to the "CTK Hackfest", as that is where the security guard is who will let you in. Miklos: +44 792 6656 927. Matt: +44 774 8022 930. I don't know peoples travel plans, but as a suggestion, people should aim to arrive by 09:30, and we start properly at 10:00. Miklos and I will be available from 09:00 so feel free to call us if you need to get a head start on the UCL branded coffee. Or if you are up early, and desperate for caffeine, there is Costa right at the entrance to the Engineering Front Building, so you could hang out there, or there is Costa in the basement of Waterstones just opposite. Matt ------------------------------------------------------ Matt Clarkson Ph.D. CMIC Software Manager Senior Research Associate m.clarkson at ucl.ac.uk Skype: drmattclarkson Centre For Medical Image Computing http://cmic.cs.ucl.ac.uk/staff/matt_clarkson/ Tel: 020 7679 0257 Fax: 020 7679 0255 Room: 2.21 Malet Place Engineering Building ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Nov 4 14:28:33 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 4 Nov 2013 09:28:33 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Hi Csaba, After you confirm that adding NO_DEFAULT_PATH to [1] works. I will coordinate with ITK folks so that they also update their FindDCMTK.cmake file. Thanks Jc [1] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter wrote: > Hi Steve, > > > > I was going to do just that, thanks for the reminder! > > I created issue https://github.com/commontk/CTK/issues/382. > > The main reason I haven't created a topic branch yet is that I would like > to hear some opinions about it first, as I don't know what consequences it > has on Linux and Mac. > > > > FYI my agenda for next week besides this small change is to try our > display tables and DICOM roles enhancement for the DICOM browser (that > Andras and I implemented during the last hackfest) against the latest > listview-based browser and integrate it if it turns out to be working fine. > > > > Thanks, > > csaba > > > > > > *From:* Steve Pieper [mailto:pieper at ibility.net] > *Sent:* October 31, 2013 16:37 > > *To:* Csaba Pinter > *Cc:* CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba - > > > > We'll be discussing open issues next week in London - can you make sure > there's a ctk issue that points to your assembla report? > > > > http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday > > > > Thanks, > > Steve > > > > On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter > wrote: > > Hi there, > > > > Any thoughts about the FindDCMTK changes proposed below? > > I'd appreciate any feedback. > > > > Thanks, > > csaba > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter > *Sent:* October 10, 2013 15:14 > *To:* CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hello, > > > > I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I > could successfully build CTK with DCMTK. > > > > As we have the same issue from time to time with CTK in Slicer (but > finally we could reproduce it, see [1]), I propose adding this flag to > FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake > change is not integrated to DCMTK. > > As my CMake knowledge is limited, I don't know if this change causes any > problem on other operating systems though. > > > > I'd appreciate to hear your opinions about this. > > > > Thank you, > > csaba > > > > [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* October 4, 2013 18:34 > *To:* Csaba Pinter > *Cc:* Andras Lasso; CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, > > > > As illustrated in the enclosed screenshot, build tree can be exported into > the CMake package registry. As some point, the DCMTK build tree has > probably been exported [1][2][3]. > > Since when building CTK, it is expected that there are no > DCMTKConfig.cmake available, the first should be failing. In your case, it > seems not to be failing because it resolves to that previous build added to > the registery. > > I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the > FindDCMTK.cmake module available in CTK. See [4] > > > > Hth > > Jc > > > > [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export > [2] > http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html > > [3] > https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 > > [4] > https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 > > > > On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter > wrote: > > Hi Jc, > > > > I tried building CTK in many ways, but the result is always the same, so > the problem is completely reproducible, at least on my computer (I haven't > tried it elsewhere yet, but I plan to). As we have been struggling with > this issue for quite a while, but haven't been able to consistently > reproduce it, this is a great opportunity to fix it once and for all. > > > > I did some digging and this is what I found: > > - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the > incorrect directory that is used later (in one of my slicer builds) > > - The reason why the DCMTK downloaded by the superbuild is not > found is most probably that it is a version that doesn't have > DCMTKConfig.cmake (as you described earlier) > > - The same thing (finding the wrong DCMTK) happens if I add > NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake > > > > Now I don't have any idea how to get the superbuild to use its own DCMTK. > > Also even if I can do a workaround and have a good build of CTK on my > machine, this is an issue that other people who want to build CTK on > Windows while already having a Slicer build have to face. > > > > Cheers, > > csaba > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* October 4, 2013 12:07 > *To:* Andras Lasso > *Cc:* Csaba Pinter; CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, Andras, > > Within the file FindDCMTK.cmake [1] provided by CTK, where would you > suggest to add the NO_CMAKE_BUILDS_PATH ? > > Let's also note that the FindDCMTK.cmake provided by ITK would have to > patched also ... > > If you can reproduce the problem, with a combination of clearing cache + > adding some "message()" statement, you should be able to find out or > confirm what is the source of the problem. > > > > Jc > > > [1] > https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake > > > > On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: > > I have this annoying issue during Slicer builds as well: my nightly slicer > builds usually break after a few days because after I configure other > projects in CMake CTK finds DCMTK of another project instead of its own. > > > > It may be due to the find_package path finding rule 5: ?Search project > build trees recently configured in a CMake GUI. This can be skipped if > NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is > building multiple dependent projects one after another.? ( > http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should > rely on rules 1-4 or disable rule 5 ? or it may be possible that something > else goes wrong and that?s why the rule 5 kicks in. > > > > Andras > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe > Fillion-Robin > *Sent:* Wednesday, October 02, 2013 11:39 AM > > > *To:* Csaba Pinter > *Cc:* CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, > > In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable > that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" > should not be empty as illustrated below: > > $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" > SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") > > > > > > Otherwise, you will find below the result of my experiment. When > configured, CTK found the expected DCMTK. > > > On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package > "python2.7-dev" doing so the following works. > > Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system > to build VTK or ITK components. Instead, I passed the following options: > -DCTK_ENABLE_Python_Wrapping:BOOL=ON > -DCTK_ENABLE_DICOM:BOOL=ON > -DCTK_BUILD_EXAMPLES > > > > $ git clone git at github.com:commontk/CTK > > $ mkdir CTK-Debug > > $ cd CTK-Debug > > $ cmake > -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake > -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON > -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK > [...] > -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( > CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates > to True > -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ > CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ CTK_ENABLE_DICOM:1 > AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ > CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt > -- Generated: > /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt > -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] > -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] > -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required by > [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] required > by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] > required by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] > required by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Core] required by > [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by > [ctkSimplePythonShell] > -- Enabling option [CTK_LIB_Scripting/Python/Core] required by > [ctkSimplePythonShell] > -- Found PythonInterp: /usr/bin/python (found version "2.7.4") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > version "2.7.4") > -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt > -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml > -- Found Git: /usr/bin/git (found version "1.8.1.2") > -- Configuring done > -- Generating done > -- Build files have been written to: /home/jchris/Projects/CTK-Debug > > $ make -j6 > [...] > [ 90%] Performing configure step for 'CTK-Configure' > [...] > -- Found PythonInterp: /usr/bin/python (found version "2.7.4") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > version "2.7.4") > -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt > -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml > -- Trying to find DCMTK expecting DCMTKConfig.cmake > -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed > -- Trying to find DCMTK relying on FindDCMTK.cmake > -- Looking for include file pthread.h > -- Looking fothe r include file pthread.h - found > -- Looking for pthread_create > -- Looking for pthread_create - not found > -- Looking for pthread_create in pthreads > -- Looking for pthread_create in pthreads - not found > -- Looking for pthread_create in pthread > -- Looking for pthread_create in pthread - found > -- Found Threads: TRUE > -- Found DCMTK: > /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config > > -- Trying to find DCMTK relying on FindDCMTK.cmake - ok > -- CTKCore: BFD support disabled > -- Configuring done > -- Generating done > [...] > -- Build files have been written to: > /home/jchris/Projects/CTK-Debug/CTK-build > > [...] > [100%] Built target CTKWidgetsCppTests > [100%] Built target CTK-build > > > > $ cd CTK-build > $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH > DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install > > Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is > explained by the fact the official DCMTK didn't integrate yet our latest > and greatest contribution [1] > > Hth > > Jc > > > [1] > https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 > > > > > > > > On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter > wrote: > > Hi all, > > > > I'm trying to build CTK separately, but I have problems with linking DCMTK. > > > > The way I build CTK: > > - Turn on CTK_BUILD_ALL > > - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and > test my changes in the CTK/Core/DICOM project) > > - Set the qmake executable > > - Configure > > - CMake complains about python paths, I set those manually > > - Configure, Generate > > - Build superbuild > > > > Then DCMTK is downloaded and built by the superbuild, but later on, CTK > projects find a completely different DCMTK directory (in my Slicer nightly > build directory). I tried to manually add the DCMTK directory to CMake, but > this variable does not exist in the superbuild (it is also not passed > down), and setting it to the inner CTK project doesn't work. > > > > Basically no matter what I do, the DCMTK path is set to whatever > find_project finds. This is what I found in CTKConfig.cmake: > > # Update CMake module path so that calling "find_package(DCMTK)" works as > expected > > # after calling "find_package(CTK)" > > # Ideally projects like DCMTK or PythonQt should provide both "Config" and > "Use" files. > > set(CMAKE_MODULE_PATH > > ${CTK_CMAKE_UTILITIES_DIR} > > ${CMAKE_MODULE_PATH} > > ) > > > > Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there > is no chance DCMTK is found correctly. > > > > Can someone please help with this? > > > > Thanks a lot, > > csaba > > > > ________________________________ > > Csaba Pinter > > Medical Software Systems Engineer > > Laboratory for Percutanous Surgery > > School of Computing > > Queen?s University > > Kingston, ON, Canada > > Email: csaba.pinter at queensu.ca > > Web: http://perk.cs.queensu.ca > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Nov 4 14:29:33 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 4 Nov 2013 09:29:33 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Based on your entry in the CTK tracker. I am assuming it is good to go ? See https://github.com/commontk/CTK/issues/382 On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Csaba, > > After you confirm that adding NO_DEFAULT_PATH to [1] works. I will > coordinate with ITK folks so that they also update their FindDCMTK.cmake > file. > > Thanks > Jc > > [1] > https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 > > > On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter wrote: > >> Hi Steve, >> >> >> >> I was going to do just that, thanks for the reminder! >> >> I created issue https://github.com/commontk/CTK/issues/382. >> >> The main reason I haven't created a topic branch yet is that I would like >> to hear some opinions about it first, as I don't know what consequences it >> has on Linux and Mac. >> >> >> >> FYI my agenda for next week besides this small change is to try our >> display tables and DICOM roles enhancement for the DICOM browser (that >> Andras and I implemented during the last hackfest) against the latest >> listview-based browser and integrate it if it turns out to be working fine. >> >> >> >> Thanks, >> >> csaba >> >> >> >> >> >> *From:* Steve Pieper [mailto:pieper at ibility.net] >> *Sent:* October 31, 2013 16:37 >> >> *To:* Csaba Pinter >> *Cc:* CTK mailing list >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba - >> >> >> >> We'll be discussing open issues next week in London - can you make sure >> there's a ctk issue that points to your assembla report? >> >> >> >> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >> >> >> >> Thanks, >> >> Steve >> >> >> >> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter >> wrote: >> >> Hi there, >> >> >> >> Any thoughts about the FindDCMTK changes proposed below? >> >> I'd appreciate any feedback. >> >> >> >> Thanks, >> >> csaba >> >> >> >> >> >> *From:* ctk-developers-bounces at commontk.org [mailto: >> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >> *Sent:* October 10, 2013 15:14 >> *To:* CTK mailing list >> >> >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hello, >> >> >> >> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I >> could successfully build CTK with DCMTK. >> >> >> >> As we have the same issue from time to time with CTK in Slicer (but >> finally we could reproduce it, see [1]), I propose adding this flag to >> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >> change is not integrated to DCMTK. >> >> As my CMake knowledge is limited, I don't know if this change causes any >> problem on other operating systems though. >> >> >> >> I'd appreciate to hear your opinions about this. >> >> >> >> Thank you, >> >> csaba >> >> >> >> [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >> >> >> >> >> >> *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] >> >> *Sent:* October 4, 2013 18:34 >> *To:* Csaba Pinter >> *Cc:* Andras Lasso; CTK mailing list >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, >> >> >> >> As illustrated in the enclosed screenshot, build tree can be exported >> into the CMake package registry. As some point, the DCMTK build tree has >> probably been exported [1][2][3]. >> >> Since when building CTK, it is expected that there are no >> DCMTKConfig.cmake available, the first should be failing. In your case, it >> seems not to be failing because it resolves to that previous build added to >> the registery. >> >> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the >> FindDCMTK.cmake module available in CTK. See [4] >> >> >> >> Hth >> >> Jc >> >> >> >> [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >> [2] >> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >> >> [3] >> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >> >> [4] >> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >> >> >> >> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter >> wrote: >> >> Hi Jc, >> >> >> >> I tried building CTK in many ways, but the result is always the same, so >> the problem is completely reproducible, at least on my computer (I haven't >> tried it elsewhere yet, but I plan to). As we have been struggling with >> this issue for quite a while, but haven't been able to consistently >> reproduce it, this is a great opportunity to fix it once and for all. >> >> >> >> I did some digging and this is what I found: >> >> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the >> incorrect directory that is used later (in one of my slicer builds) >> >> - The reason why the DCMTK downloaded by the superbuild is not >> found is most probably that it is a version that doesn't have >> DCMTKConfig.cmake (as you described earlier) >> >> - The same thing (finding the wrong DCMTK) happens if I add >> NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >> >> >> >> Now I don't have any idea how to get the superbuild to use its own DCMTK. >> >> Also even if I can do a workaround and have a good build of CTK on my >> machine, this is an issue that other people who want to build CTK on >> Windows while already having a Slicer build have to face. >> >> >> >> Cheers, >> >> csaba >> >> >> >> >> >> *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] >> >> *Sent:* October 4, 2013 12:07 >> *To:* Andras Lasso >> *Cc:* Csaba Pinter; CTK mailing list >> >> >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, Andras, >> >> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >> suggest to add the NO_CMAKE_BUILDS_PATH ? >> >> Let's also note that the FindDCMTK.cmake provided by ITK would have to >> patched also ... >> >> If you can reproduce the problem, with a combination of clearing cache + >> adding some "message()" statement, you should be able to find out or >> confirm what is the source of the problem. >> >> >> >> Jc >> >> >> [1] >> >> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >> >> >> >> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: >> >> I have this annoying issue during Slicer builds as well: my nightly >> slicer builds usually break after a few days because after I configure >> other projects in CMake CTK finds DCMTK of another project instead of its >> own. >> >> >> >> It may be due to the find_package path finding rule 5: ?Search project >> build trees recently configured in a CMake GUI. This can be skipped if >> NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is >> building multiple dependent projects one after another.? ( >> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should >> rely on rules 1-4 or disable rule 5 ? or it may be possible that something >> else goes wrong and that?s why the rule 5 kicks in. >> >> >> >> Andras >> >> >> >> >> >> *From:* ctk-developers-bounces at commontk.org [mailto: >> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >> Fillion-Robin >> *Sent:* Wednesday, October 02, 2013 11:39 AM >> >> >> *To:* Csaba Pinter >> *Cc:* CTK mailing list >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, >> >> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable >> that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" >> should not be empty as illustrated below: >> >> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >> SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") >> >> >> >> >> >> Otherwise, you will find below the result of my experiment. When >> configured, CTK found the expected DCMTK. >> >> >> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >> "python2.7-dev" doing so the following works. >> >> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system >> to build VTK or ITK components. Instead, I passed the following options: >> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >> -DCTK_ENABLE_DICOM:BOOL=ON >> -DCTK_BUILD_EXAMPLES >> >> >> >> $ git clone git at github.com:commontk/CTK >> >> $ mkdir CTK-Debug >> >> $ cd CTK-Debug >> >> $ cmake >> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >> [...] >> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( >> CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates >> to True >> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 >> AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >> -- Generated: >> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required >> by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >> required by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >> required by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] >> required by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >> [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >> [ctkSimplePythonShell] >> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >> [ctkSimplePythonShell] >> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >> version "2.7.4") >> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >> -- Found Git: /usr/bin/git (found version "1.8.1.2") >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >> >> $ make -j6 >> [...] >> [ 90%] Performing configure step for 'CTK-Configure' >> [...] >> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >> version "2.7.4") >> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >> -- Trying to find DCMTK expecting DCMTKConfig.cmake >> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >> -- Trying to find DCMTK relying on FindDCMTK.cmake >> -- Looking for include file pthread.h >> -- Looking fothe r include file pthread.h - found >> -- Looking for pthread_create >> -- Looking for pthread_create - not found >> -- Looking for pthread_create in pthreads >> -- Looking for pthread_create in pthreads - not found >> -- Looking for pthread_create in pthread >> -- Looking for pthread_create in pthread - found >> -- Found Threads: TRUE >> -- Found DCMTK: >> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >> >> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >> -- CTKCore: BFD support disabled >> -- Configuring done >> -- Generating done >> [...] >> -- Build files have been written to: >> /home/jchris/Projects/CTK-Debug/CTK-build >> >> [...] >> [100%] Built target CTKWidgetsCppTests >> [100%] Built target CTK-build >> >> >> >> $ cd CTK-build >> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >> >> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is >> explained by the fact the official DCMTK didn't integrate yet our latest >> and greatest contribution [1] >> >> Hth >> >> Jc >> >> >> [1] >> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >> >> >> >> >> >> >> >> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter >> wrote: >> >> Hi all, >> >> >> >> I'm trying to build CTK separately, but I have problems with linking >> DCMTK. >> >> >> >> The way I build CTK: >> >> - Turn on CTK_BUILD_ALL >> >> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and >> test my changes in the CTK/Core/DICOM project) >> >> - Set the qmake executable >> >> - Configure >> >> - CMake complains about python paths, I set those manually >> >> - Configure, Generate >> >> - Build superbuild >> >> >> >> Then DCMTK is downloaded and built by the superbuild, but later on, CTK >> projects find a completely different DCMTK directory (in my Slicer nightly >> build directory). I tried to manually add the DCMTK directory to CMake, but >> this variable does not exist in the superbuild (it is also not passed >> down), and setting it to the inner CTK project doesn't work. >> >> >> >> Basically no matter what I do, the DCMTK path is set to whatever >> find_project finds. This is what I found in CTKConfig.cmake: >> >> # Update CMake module path so that calling "find_package(DCMTK)" works as >> expected >> >> # after calling "find_package(CTK)" >> >> # Ideally projects like DCMTK or PythonQt should provide both "Config" >> and "Use" files. >> >> set(CMAKE_MODULE_PATH >> >> ${CTK_CMAKE_UTILITIES_DIR} >> >> ${CMAKE_MODULE_PATH} >> >> ) >> >> >> >> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there >> is no chance DCMTK is found correctly. >> >> >> >> Can someone please help with this? >> >> >> >> Thanks a lot, >> >> csaba >> >> >> >> ________________________________ >> >> Csaba Pinter >> >> Medical Software Systems Engineer >> >> Laboratory for Percutanous Surgery >> >> School of Computing >> >> Queen?s University >> >> Kingston, ON, Canada >> >> Email: csaba.pinter at queensu.ca >> >> Web: http://perk.cs.queensu.ca >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you >> in error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- > +1 919 869 8849 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.pinter at queensu.ca Mon Nov 4 14:34:31 2013 From: csaba.pinter at queensu.ca (Csaba Pinter) Date: Mon, 4 Nov 2013 14:34:31 +0000 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> Hi JC, Yes, it seems to have solved our CTK build problem. The reason I was asking about opinions is that I don't know what repercussions it may have on other platforms. If it seems OK the I'd appreciate propagating it to the CTK core or ITK. I can create a CTK topic branch containing the change if it makes the process easier. Thanks, csaba From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: November 4, 2013 09:30 To: Csaba Pinter Cc: pieper at bwh.harvard.edu; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Based on your entry in the CTK tracker. I am assuming it is good to go ? See https://github.com/commontk/CTK/issues/382 On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin > wrote: Hi Csaba, After you confirm that adding NO_DEFAULT_PATH to [1] works. I will coordinate with ITK folks so that they also update their FindDCMTK.cmake file. Thanks Jc [1] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter > wrote: Hi Steve, I was going to do just that, thanks for the reminder! I created issue https://github.com/commontk/CTK/issues/382. The main reason I haven't created a topic branch yet is that I would like to hear some opinions about it first, as I don't know what consequences it has on Linux and Mac. FYI my agenda for next week besides this small change is to try our display tables and DICOM roles enhancement for the DICOM browser (that Andras and I implemented during the last hackfest) against the latest listview-based browser and integrate it if it turns out to be working fine. Thanks, csaba From: Steve Pieper [mailto:pieper at ibility.net] Sent: October 31, 2013 16:37 To: Csaba Pinter Cc: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba - We'll be discussing open issues next week in London - can you make sure there's a ctk issue that points to your assembla report? http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday Thanks, Steve On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter > wrote: Hi there, Any thoughts about the FindDCMTK changes proposed below? I'd appreciate any feedback. Thanks, csaba From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Csaba Pinter Sent: October 10, 2013 15:14 To: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hello, I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I could successfully build CTK with DCMTK. As we have the same issue from time to time with CTK in Slicer (but finally we could reproduce it, see [1]), I propose adding this flag to FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake change is not integrated to DCMTK. As my CMake knowledge is limited, I don't know if this change causes any problem on other operating systems though. I'd appreciate to hear your opinions about this. Thank you, csaba [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: October 4, 2013 18:34 To: Csaba Pinter Cc: Andras Lasso; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, As illustrated in the enclosed screenshot, build tree can be exported into the CMake package registry. As some point, the DCMTK build tree has probably been exported [1][2][3]. Since when building CTK, it is expected that there are no DCMTKConfig.cmake available, the first should be failing. In your case, it seems not to be failing because it resolves to that previous build added to the registery. I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the FindDCMTK.cmake module available in CTK. See [4] Hth Jc [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export [2] http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html [3] https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 [4] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter > wrote: Hi Jc, I tried building CTK in many ways, but the result is always the same, so the problem is completely reproducible, at least on my computer (I haven't tried it elsewhere yet, but I plan to). As we have been struggling with this issue for quite a while, but haven't been able to consistently reproduce it, this is a great opportunity to fix it once and for all. I did some digging and this is what I found: - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the incorrect directory that is used later (in one of my slicer builds) - The reason why the DCMTK downloaded by the superbuild is not found is most probably that it is a version that doesn't have DCMTKConfig.cmake (as you described earlier) - The same thing (finding the wrong DCMTK) happens if I add NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake Now I don't have any idea how to get the superbuild to use its own DCMTK. Also even if I can do a workaround and have a good build of CTK on my machine, this is an issue that other people who want to build CTK on Windows while already having a Slicer build have to face. Cheers, csaba From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: October 4, 2013 12:07 To: Andras Lasso Cc: Csaba Pinter; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, Andras, Within the file FindDCMTK.cmake [1] provided by CTK, where would you suggest to add the NO_CMAKE_BUILDS_PATH ? Let's also note that the FindDCMTK.cmake provided by ITK would have to patched also ... If you can reproduce the problem, with a combination of clearing cache + adding some "message()" statement, you should be able to find out or confirm what is the source of the problem. Jc [1] https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso > wrote: I have this annoying issue during Slicer builds as well: my nightly slicer builds usually break after a few days because after I configure other projects in CMake CTK finds DCMTK of another project instead of its own. It may be due to the find_package path finding rule 5: "Search project build trees recently configured in a CMake GUI. This can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is building multiple dependent projects one after another." (http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should rely on rules 1-4 or disable rule 5 - or it may be possible that something else goes wrong and that's why the rule 5 kicks in. Andras From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Jean-Christophe Fillion-Robin Sent: Wednesday, October 02, 2013 11:39 AM To: Csaba Pinter Cc: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") Otherwise, you will find below the result of my experiment. When configured, CTK found the expected DCMTK. On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package "python2.7-dev" doing so the following works. Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system to build VTK or ITK components. Instead, I passed the following options: -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON -DCTK_BUILD_EXAMPLES $ git clone git at github.com:commontk/CTK $ mkdir CTK-Debug $ cd CTK-Debug $ cmake -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK [...] -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates to True -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Core] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by [ctkSimplePythonShell] -- Enabling option [CTK_LIB_Scripting/Python/Core] required by [ctkSimplePythonShell] -- Found PythonInterp: /usr/bin/python (found version "2.7.4") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.4") -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml -- Found Git: /usr/bin/git (found version "1.8.1.2") -- Configuring done -- Generating done -- Build files have been written to: /home/jchris/Projects/CTK-Debug $ make -j6 [...] [ 90%] Performing configure step for 'CTK-Configure' [...] -- Found PythonInterp: /usr/bin/python (found version "2.7.4") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.4") -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml -- Trying to find DCMTK expecting DCMTKConfig.cmake -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed -- Trying to find DCMTK relying on FindDCMTK.cmake -- Looking for include file pthread.h -- Looking fothe r include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Found DCMTK: /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config -- Trying to find DCMTK relying on FindDCMTK.cmake - ok -- CTKCore: BFD support disabled -- Configuring done -- Generating done [...] -- Build files have been written to: /home/jchris/Projects/CTK-Debug/CTK-build [...] [100%] Built target CTKWidgetsCppTests [100%] Built target CTK-build $ cd CTK-build $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is explained by the fact the official DCMTK didn't integrate yet our latest and greatest contribution [1] Hth Jc [1] https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter > wrote: Hi all, I'm trying to build CTK separately, but I have problems with linking DCMTK. The way I build CTK: - Turn on CTK_BUILD_ALL - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and test my changes in the CTK/Core/DICOM project) - Set the qmake executable - Configure - CMake complains about python paths, I set those manually - Configure, Generate - Build superbuild Then DCMTK is downloaded and built by the superbuild, but later on, CTK projects find a completely different DCMTK directory (in my Slicer nightly build directory). I tried to manually add the DCMTK directory to CMake, but this variable does not exist in the superbuild (it is also not passed down), and setting it to the inner CTK project doesn't work. Basically no matter what I do, the DCMTK path is set to whatever find_project finds. This is what I found in CTKConfig.cmake: # Update CMake module path so that calling "find_package(DCMTK)" works as expected # after calling "find_package(CTK)" # Ideally projects like DCMTK or PythonQt should provide both "Config" and "Use" files. set(CMAKE_MODULE_PATH ${CTK_CMAKE_UTILITIES_DIR} ${CMAKE_MODULE_PATH} ) Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there is no chance DCMTK is found correctly. Can someone please help with this? Thanks a lot, csaba ________________________________ Csaba Pinter Medical Software Systems Engineer Laboratory for Percutanous Surgery School of Computing Queen's University Kingston, ON, Canada Email: csaba.pinter at queensu.ca Web: http://perk.cs.queensu.ca _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -- +1 919 869 8849 -- +1 919 869 8849 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 4 15:01:54 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 4 Nov 2013 10:01:54 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Hi Csaba, Jc - London calling (always wanted to say that). We talked over the issue a bit and didn't see any obvious issues but there was a request from some folks for a further discussion of the underlying issue so we put it on the agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work for you two? Most of the work here this week so far is on CLI, XNAT/REST API, and DICOM. http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 -Steve On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter wrote: > Hi JC, > > > > Yes, it seems to have solved our CTK build problem. The reason I was > asking about opinions is that I don't know what repercussions it may have > on other platforms. > > If it seems OK the I'd appreciate propagating it to the CTK core or ITK. I > can create a CTK topic branch containing the change if it makes the process > easier. > > > > Thanks, > > csaba > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* November 4, 2013 09:30 > *To:* Csaba Pinter > *Cc:* pieper at bwh.harvard.edu; CTK mailing list > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Based on your entry in the CTK tracker. I am assuming it is good to go ? > See https://github.com/commontk/CTK/issues/382 > > > > On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > Hi Csaba, > > After you confirm that adding NO_DEFAULT_PATH to [1] works. I will > coordinate with ITK folks so that they also update their FindDCMTK.cmake > file. > > Thanks > > Jc > > > [1] > https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 > > > > On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter > wrote: > > Hi Steve, > > > > I was going to do just that, thanks for the reminder! > > I created issue https://github.com/commontk/CTK/issues/382. > > The main reason I haven't created a topic branch yet is that I would like > to hear some opinions about it first, as I don't know what consequences it > has on Linux and Mac. > > > > FYI my agenda for next week besides this small change is to try our > display tables and DICOM roles enhancement for the DICOM browser (that > Andras and I implemented during the last hackfest) against the latest > listview-based browser and integrate it if it turns out to be working fine. > > > > Thanks, > > csaba > > > > > > *From:* Steve Pieper [mailto:pieper at ibility.net] > *Sent:* October 31, 2013 16:37 > > > *To:* Csaba Pinter > *Cc:* CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba - > > > > We'll be discussing open issues next week in London - can you make sure > there's a ctk issue that points to your assembla report? > > > > http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday > > > > Thanks, > > Steve > > > > On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter > wrote: > > Hi there, > > > > Any thoughts about the FindDCMTK changes proposed below? > > I'd appreciate any feedback. > > > > Thanks, > > csaba > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter > *Sent:* October 10, 2013 15:14 > *To:* CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hello, > > > > I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I > could successfully build CTK with DCMTK. > > > > As we have the same issue from time to time with CTK in Slicer (but > finally we could reproduce it, see [1]), I propose adding this flag to > FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake > change is not integrated to DCMTK. > > As my CMake knowledge is limited, I don't know if this change causes any > problem on other operating systems though. > > > > I'd appreciate to hear your opinions about this. > > > > Thank you, > > csaba > > > > [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* October 4, 2013 18:34 > *To:* Csaba Pinter > *Cc:* Andras Lasso; CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, > > > > As illustrated in the enclosed screenshot, build tree can be exported into > the CMake package registry. As some point, the DCMTK build tree has > probably been exported [1][2][3]. > > Since when building CTK, it is expected that there are no > DCMTKConfig.cmake available, the first should be failing. In your case, it > seems not to be failing because it resolves to that previous build added to > the registery. > > I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the > FindDCMTK.cmake module available in CTK. See [4] > > > > Hth > > Jc > > > > [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export > [2] > http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html > > [3] > https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 > > [4] > https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 > > > > On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter > wrote: > > Hi Jc, > > > > I tried building CTK in many ways, but the result is always the same, so > the problem is completely reproducible, at least on my computer (I haven't > tried it elsewhere yet, but I plan to). As we have been struggling with > this issue for quite a while, but haven't been able to consistently > reproduce it, this is a great opportunity to fix it once and for all. > > > > I did some digging and this is what I found: > > - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the > incorrect directory that is used later (in one of my slicer builds) > > - The reason why the DCMTK downloaded by the superbuild is not > found is most probably that it is a version that doesn't have > DCMTKConfig.cmake (as you described earlier) > > - The same thing (finding the wrong DCMTK) happens if I add > NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake > > > > Now I don't have any idea how to get the superbuild to use its own DCMTK. > > Also even if I can do a workaround and have a good build of CTK on my > machine, this is an issue that other people who want to build CTK on > Windows while already having a Slicer build have to face. > > > > Cheers, > > csaba > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* October 4, 2013 12:07 > *To:* Andras Lasso > *Cc:* Csaba Pinter; CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, Andras, > > Within the file FindDCMTK.cmake [1] provided by CTK, where would you > suggest to add the NO_CMAKE_BUILDS_PATH ? > > Let's also note that the FindDCMTK.cmake provided by ITK would have to > patched also ... > > If you can reproduce the problem, with a combination of clearing cache + > adding some "message()" statement, you should be able to find out or > confirm what is the source of the problem. > > > > Jc > > > [1] > https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake > > > > On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: > > I have this annoying issue during Slicer builds as well: my nightly slicer > builds usually break after a few days because after I configure other > projects in CMake CTK finds DCMTK of another project instead of its own. > > > > It may be due to the find_package path finding rule 5: ?Search project > build trees recently configured in a CMake GUI. This can be skipped if > NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is > building multiple dependent projects one after another.? ( > http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should > rely on rules 1-4 or disable rule 5 ? or it may be possible that something > else goes wrong and that?s why the rule 5 kicks in. > > > > Andras > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe > Fillion-Robin > *Sent:* Wednesday, October 02, 2013 11:39 AM > > > *To:* Csaba Pinter > *Cc:* CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, > > In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable > that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" > should not be empty as illustrated below: > > $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" > SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") > > > > > > Otherwise, you will find below the result of my experiment. When > configured, CTK found the expected DCMTK. > > > On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package > "python2.7-dev" doing so the following works. > > Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system > to build VTK or ITK components. Instead, I passed the following options: > -DCTK_ENABLE_Python_Wrapping:BOOL=ON > -DCTK_ENABLE_DICOM:BOOL=ON > -DCTK_BUILD_EXAMPLES > > > > $ git clone git at github.com:commontk/CTK > > $ mkdir CTK-Debug > > $ cd CTK-Debug > > $ cmake > -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake > -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON > -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK > [...] > -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( > CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates > to True > -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ > CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ CTK_ENABLE_DICOM:1 > AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ > CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt > -- Generated: > /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt > -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] > -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] > -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required by > [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] required > by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] > required by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] > required by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Core] required by > [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by > [ctkSimplePythonShell] > -- Enabling option [CTK_LIB_Scripting/Python/Core] required by > [ctkSimplePythonShell] > -- Found PythonInterp: /usr/bin/python (found version "2.7.4") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > version "2.7.4") > -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt > -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml > -- Found Git: /usr/bin/git (found version "1.8.1.2") > -- Configuring done > -- Generating done > -- Build files have been written to: /home/jchris/Projects/CTK-Debug > > $ make -j6 > [...] > [ 90%] Performing configure step for 'CTK-Configure' > [...] > -- Found PythonInterp: /usr/bin/python (found version "2.7.4") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > version "2.7.4") > -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt > -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml > -- Trying to find DCMTK expecting DCMTKConfig.cmake > -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed > -- Trying to find DCMTK relying on FindDCMTK.cmake > -- Looking for include file pthread.h > -- Looking fothe r include file pthread.h - found > -- Looking for pthread_create > -- Looking for pthread_create - not found > -- Looking for pthread_create in pthreads > -- Looking for pthread_create in pthreads - not found > -- Looking for pthread_create in pthread > -- Looking for pthread_create in pthread - found > -- Found Threads: TRUE > -- Found DCMTK: > /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config > > -- Trying to find DCMTK relying on FindDCMTK.cmake - ok > -- CTKCore: BFD support disabled > -- Configuring done > -- Generating done > [...] > -- Build files have been written to: > /home/jchris/Projects/CTK-Debug/CTK-build > > [...] > [100%] Built target CTKWidgetsCppTests > [100%] Built target CTK-build > > > > $ cd CTK-build > $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH > DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install > > Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is > explained by the fact the official DCMTK didn't integrate yet our latest > and greatest contribution [1] > > Hth > > Jc > > > [1] > https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 > > > > > > > > On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter > wrote: > > Hi all, > > > > I'm trying to build CTK separately, but I have problems with linking DCMTK. > > > > The way I build CTK: > > - Turn on CTK_BUILD_ALL > > - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and > test my changes in the CTK/Core/DICOM project) > > - Set the qmake executable > > - Configure > > - CMake complains about python paths, I set those manually > > - Configure, Generate > > - Build superbuild > > > > Then DCMTK is downloaded and built by the superbuild, but later on, CTK > projects find a completely different DCMTK directory (in my Slicer nightly > build directory). I tried to manually add the DCMTK directory to CMake, but > this variable does not exist in the superbuild (it is also not passed > down), and setting it to the inner CTK project doesn't work. > > > > Basically no matter what I do, the DCMTK path is set to whatever > find_project finds. This is what I found in CTKConfig.cmake: > > # Update CMake module path so that calling "find_package(DCMTK)" works as > expected > > # after calling "find_package(CTK)" > > # Ideally projects like DCMTK or PythonQt should provide both "Config" and > "Use" files. > > set(CMAKE_MODULE_PATH > > ${CTK_CMAKE_UTILITIES_DIR} > > ${CMAKE_MODULE_PATH} > > ) > > > > Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there > is no chance DCMTK is found correctly. > > > > Can someone please help with this? > > > > Thanks a lot, > > csaba > > > > ________________________________ > > Csaba Pinter > > Medical Software Systems Engineer > > Laboratory for Percutanous Surgery > > School of Computing > > Queen?s University > > Kingston, ON, Canada > > Email: csaba.pinter at queensu.ca > > Web: http://perk.cs.queensu.ca > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.pinter at queensu.ca Mon Nov 4 15:21:44 2013 From: csaba.pinter at queensu.ca (Csaba Pinter) Date: Mon, 4 Nov 2013 15:21:44 +0000 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Hi Steve, Definitely, I can join the hangout tomorrow. Thanks for discussing the issue! Are the DKFZ fellas going to work on the list-based DICOM browser? We'd like to at least start integrating the display database and DICOM roles we implemented last time. Thanks, csaba From: Steve Pieper [mailto:pieper at ibility.net] Sent: November 4, 2013 10:02 To: Csaba Pinter Cc: Jean-Christophe Fillion-Robin; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, Jc - London calling (always wanted to say that). We talked over the issue a bit and didn't see any obvious issues but there was a request from some folks for a further discussion of the underlying issue so we put it on the agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work for you two? Most of the work here this week so far is on CLI, XNAT/REST API, and DICOM. http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 -Steve On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter > wrote: Hi JC, Yes, it seems to have solved our CTK build problem. The reason I was asking about opinions is that I don't know what repercussions it may have on other platforms. If it seems OK the I'd appreciate propagating it to the CTK core or ITK. I can create a CTK topic branch containing the change if it makes the process easier. Thanks, csaba From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: November 4, 2013 09:30 To: Csaba Pinter Cc: pieper at bwh.harvard.edu; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Based on your entry in the CTK tracker. I am assuming it is good to go ? See https://github.com/commontk/CTK/issues/382 On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin > wrote: Hi Csaba, After you confirm that adding NO_DEFAULT_PATH to [1] works. I will coordinate with ITK folks so that they also update their FindDCMTK.cmake file. Thanks Jc [1] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter > wrote: Hi Steve, I was going to do just that, thanks for the reminder! I created issue https://github.com/commontk/CTK/issues/382. The main reason I haven't created a topic branch yet is that I would like to hear some opinions about it first, as I don't know what consequences it has on Linux and Mac. FYI my agenda for next week besides this small change is to try our display tables and DICOM roles enhancement for the DICOM browser (that Andras and I implemented during the last hackfest) against the latest listview-based browser and integrate it if it turns out to be working fine. Thanks, csaba From: Steve Pieper [mailto:pieper at ibility.net] Sent: October 31, 2013 16:37 To: Csaba Pinter Cc: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba - We'll be discussing open issues next week in London - can you make sure there's a ctk issue that points to your assembla report? http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday Thanks, Steve On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter > wrote: Hi there, Any thoughts about the FindDCMTK changes proposed below? I'd appreciate any feedback. Thanks, csaba From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Csaba Pinter Sent: October 10, 2013 15:14 To: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hello, I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I could successfully build CTK with DCMTK. As we have the same issue from time to time with CTK in Slicer (but finally we could reproduce it, see [1]), I propose adding this flag to FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake change is not integrated to DCMTK. As my CMake knowledge is limited, I don't know if this change causes any problem on other operating systems though. I'd appreciate to hear your opinions about this. Thank you, csaba [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: October 4, 2013 18:34 To: Csaba Pinter Cc: Andras Lasso; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, As illustrated in the enclosed screenshot, build tree can be exported into the CMake package registry. As some point, the DCMTK build tree has probably been exported [1][2][3]. Since when building CTK, it is expected that there are no DCMTKConfig.cmake available, the first should be failing. In your case, it seems not to be failing because it resolves to that previous build added to the registery. I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the FindDCMTK.cmake module available in CTK. See [4] Hth Jc [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export [2] http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html [3] https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 [4] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter > wrote: Hi Jc, I tried building CTK in many ways, but the result is always the same, so the problem is completely reproducible, at least on my computer (I haven't tried it elsewhere yet, but I plan to). As we have been struggling with this issue for quite a while, but haven't been able to consistently reproduce it, this is a great opportunity to fix it once and for all. I did some digging and this is what I found: - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the incorrect directory that is used later (in one of my slicer builds) - The reason why the DCMTK downloaded by the superbuild is not found is most probably that it is a version that doesn't have DCMTKConfig.cmake (as you described earlier) - The same thing (finding the wrong DCMTK) happens if I add NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake Now I don't have any idea how to get the superbuild to use its own DCMTK. Also even if I can do a workaround and have a good build of CTK on my machine, this is an issue that other people who want to build CTK on Windows while already having a Slicer build have to face. Cheers, csaba From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: October 4, 2013 12:07 To: Andras Lasso Cc: Csaba Pinter; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, Andras, Within the file FindDCMTK.cmake [1] provided by CTK, where would you suggest to add the NO_CMAKE_BUILDS_PATH ? Let's also note that the FindDCMTK.cmake provided by ITK would have to patched also ... If you can reproduce the problem, with a combination of clearing cache + adding some "message()" statement, you should be able to find out or confirm what is the source of the problem. Jc [1] https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso > wrote: I have this annoying issue during Slicer builds as well: my nightly slicer builds usually break after a few days because after I configure other projects in CMake CTK finds DCMTK of another project instead of its own. It may be due to the find_package path finding rule 5: "Search project build trees recently configured in a CMake GUI. This can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is building multiple dependent projects one after another." (http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should rely on rules 1-4 or disable rule 5 - or it may be possible that something else goes wrong and that's why the rule 5 kicks in. Andras From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Jean-Christophe Fillion-Robin Sent: Wednesday, October 02, 2013 11:39 AM To: Csaba Pinter Cc: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") Otherwise, you will find below the result of my experiment. When configured, CTK found the expected DCMTK. On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package "python2.7-dev" doing so the following works. Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system to build VTK or ITK components. Instead, I passed the following options: -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON -DCTK_BUILD_EXAMPLES $ git clone git at github.com:commontk/CTK $ mkdir CTK-Debug $ cd CTK-Debug $ cmake -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK [...] -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates to True -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Core] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by [ctkSimplePythonShell] -- Enabling option [CTK_LIB_Scripting/Python/Core] required by [ctkSimplePythonShell] -- Found PythonInterp: /usr/bin/python (found version "2.7.4") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.4") -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml -- Found Git: /usr/bin/git (found version "1.8.1.2") -- Configuring done -- Generating done -- Build files have been written to: /home/jchris/Projects/CTK-Debug $ make -j6 [...] [ 90%] Performing configure step for 'CTK-Configure' [...] -- Found PythonInterp: /usr/bin/python (found version "2.7.4") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.4") -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml -- Trying to find DCMTK expecting DCMTKConfig.cmake -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed -- Trying to find DCMTK relying on FindDCMTK.cmake -- Looking for include file pthread.h -- Looking fothe r include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Found DCMTK: /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config -- Trying to find DCMTK relying on FindDCMTK.cmake - ok -- CTKCore: BFD support disabled -- Configuring done -- Generating done [...] -- Build files have been written to: /home/jchris/Projects/CTK-Debug/CTK-build [...] [100%] Built target CTKWidgetsCppTests [100%] Built target CTK-build $ cd CTK-build $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is explained by the fact the official DCMTK didn't integrate yet our latest and greatest contribution [1] Hth Jc [1] https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter > wrote: Hi all, I'm trying to build CTK separately, but I have problems with linking DCMTK. The way I build CTK: - Turn on CTK_BUILD_ALL - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and test my changes in the CTK/Core/DICOM project) - Set the qmake executable - Configure - CMake complains about python paths, I set those manually - Configure, Generate - Build superbuild Then DCMTK is downloaded and built by the superbuild, but later on, CTK projects find a completely different DCMTK directory (in my Slicer nightly build directory). I tried to manually add the DCMTK directory to CMake, but this variable does not exist in the superbuild (it is also not passed down), and setting it to the inner CTK project doesn't work. Basically no matter what I do, the DCMTK path is set to whatever find_project finds. This is what I found in CTKConfig.cmake: # Update CMake module path so that calling "find_package(DCMTK)" works as expected # after calling "find_package(CTK)" # Ideally projects like DCMTK or PythonQt should provide both "Config" and "Use" files. set(CMAKE_MODULE_PATH ${CTK_CMAKE_UTILITIES_DIR} ${CMAKE_MODULE_PATH} ) Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there is no chance DCMTK is found correctly. Can someone please help with this? Thanks a lot, csaba ________________________________ Csaba Pinter Medical Software Systems Engineer Laboratory for Percutanous Surgery School of Computing Queen's University Kingston, ON, Canada Email: csaba.pinter at queensu.ca Web: http://perk.cs.queensu.ca _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -- +1 919 869 8849 -- +1 919 869 8849 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 4 16:04:38 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 4 Nov 2013 11:04:38 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Hi Csaba - Andreas is here and working on some of the coding input from Julien (but the emails to him from the CTK list aren't working right now for some reason). -Steve On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter wrote: > Hi Steve, > > > > Definitely, I can join the hangout tomorrow. Thanks for discussing the > issue! > > > > Are the DKFZ fellas going to work on the list-based DICOM browser? We'd > like to at least start integrating the display database and DICOM roles we > implemented last time. > > > > Thanks, > > csaba > > > > > > *From:* Steve Pieper [mailto:pieper at ibility.net] > *Sent:* November 4, 2013 10:02 > *To:* Csaba Pinter > *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, Jc - > > > > London calling (always wanted to say that). We talked over the issue a > bit and didn't see any obvious issues but there was a request from some > folks for a further discussion of the underlying issue so we put it on the > agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work > for you two? > > > > Most of the work here this week so far is on CLI, XNAT/REST API, and DICOM. > > > > http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 > > > > -Steve > > > > On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter > wrote: > > Hi JC, > > > > Yes, it seems to have solved our CTK build problem. The reason I was > asking about opinions is that I don't know what repercussions it may have > on other platforms. > > If it seems OK the I'd appreciate propagating it to the CTK core or ITK. I > can create a CTK topic branch containing the change if it makes the process > easier. > > > > Thanks, > > csaba > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* November 4, 2013 09:30 > *To:* Csaba Pinter > *Cc:* pieper at bwh.harvard.edu; CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Based on your entry in the CTK tracker. I am assuming it is good to go ? > See https://github.com/commontk/CTK/issues/382 > > > > On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > Hi Csaba, > > After you confirm that adding NO_DEFAULT_PATH to [1] works. I will > coordinate with ITK folks so that they also update their FindDCMTK.cmake > file. > > Thanks > > Jc > > > [1] > https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 > > > > On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter > wrote: > > Hi Steve, > > > > I was going to do just that, thanks for the reminder! > > I created issue https://github.com/commontk/CTK/issues/382. > > The main reason I haven't created a topic branch yet is that I would like > to hear some opinions about it first, as I don't know what consequences it > has on Linux and Mac. > > > > FYI my agenda for next week besides this small change is to try our > display tables and DICOM roles enhancement for the DICOM browser (that > Andras and I implemented during the last hackfest) against the latest > listview-based browser and integrate it if it turns out to be working fine. > > > > Thanks, > > csaba > > > > > > *From:* Steve Pieper [mailto:pieper at ibility.net] > *Sent:* October 31, 2013 16:37 > > > *To:* Csaba Pinter > *Cc:* CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba - > > > > We'll be discussing open issues next week in London - can you make sure > there's a ctk issue that points to your assembla report? > > > > http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday > > > > Thanks, > > Steve > > > > On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter > wrote: > > Hi there, > > > > Any thoughts about the FindDCMTK changes proposed below? > > I'd appreciate any feedback. > > > > Thanks, > > csaba > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter > *Sent:* October 10, 2013 15:14 > *To:* CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hello, > > > > I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I > could successfully build CTK with DCMTK. > > > > As we have the same issue from time to time with CTK in Slicer (but > finally we could reproduce it, see [1]), I propose adding this flag to > FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake > change is not integrated to DCMTK. > > As my CMake knowledge is limited, I don't know if this change causes any > problem on other operating systems though. > > > > I'd appreciate to hear your opinions about this. > > > > Thank you, > > csaba > > > > [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* October 4, 2013 18:34 > *To:* Csaba Pinter > *Cc:* Andras Lasso; CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, > > > > As illustrated in the enclosed screenshot, build tree can be exported into > the CMake package registry. As some point, the DCMTK build tree has > probably been exported [1][2][3]. > > Since when building CTK, it is expected that there are no > DCMTKConfig.cmake available, the first should be failing. In your case, it > seems not to be failing because it resolves to that previous build added to > the registery. > > I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the > FindDCMTK.cmake module available in CTK. See [4] > > > > Hth > > Jc > > > > [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export > [2] > http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html > > [3] > https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 > > [4] > https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 > > > > On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter > wrote: > > Hi Jc, > > > > I tried building CTK in many ways, but the result is always the same, so > the problem is completely reproducible, at least on my computer (I haven't > tried it elsewhere yet, but I plan to). As we have been struggling with > this issue for quite a while, but haven't been able to consistently > reproduce it, this is a great opportunity to fix it once and for all. > > > > I did some digging and this is what I found: > > - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the > incorrect directory that is used later (in one of my slicer builds) > > - The reason why the DCMTK downloaded by the superbuild is not > found is most probably that it is a version that doesn't have > DCMTKConfig.cmake (as you described earlier) > > - The same thing (finding the wrong DCMTK) happens if I add > NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake > > > > Now I don't have any idea how to get the superbuild to use its own DCMTK. > > Also even if I can do a workaround and have a good build of CTK on my > machine, this is an issue that other people who want to build CTK on > Windows while already having a Slicer build have to face. > > > > Cheers, > > csaba > > > > > > *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > > *Sent:* October 4, 2013 12:07 > *To:* Andras Lasso > *Cc:* Csaba Pinter; CTK mailing list > > > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, Andras, > > Within the file FindDCMTK.cmake [1] provided by CTK, where would you > suggest to add the NO_CMAKE_BUILDS_PATH ? > > Let's also note that the FindDCMTK.cmake provided by ITK would have to > patched also ... > > If you can reproduce the problem, with a combination of clearing cache + > adding some "message()" statement, you should be able to find out or > confirm what is the source of the problem. > > > > Jc > > > [1] > https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake > > > > On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: > > I have this annoying issue during Slicer builds as well: my nightly slicer > builds usually break after a few days because after I configure other > projects in CMake CTK finds DCMTK of another project instead of its own. > > > > It may be due to the find_package path finding rule 5: ?Search project > build trees recently configured in a CMake GUI. This can be skipped if > NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is > building multiple dependent projects one after another.? ( > http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should > rely on rules 1-4 or disable rule 5 ? or it may be possible that something > else goes wrong and that?s why the rule 5 kicks in. > > > > Andras > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe > Fillion-Robin > *Sent:* Wednesday, October 02, 2013 11:39 AM > > > *To:* Csaba Pinter > *Cc:* CTK mailing list > *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly > > > > Hi Csaba, > > In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable > that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" > should not be empty as illustrated below: > > $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" > SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") > > > > > > Otherwise, you will find below the result of my experiment. When > configured, CTK found the expected DCMTK. > > > On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package > "python2.7-dev" doing so the following works. > > Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system > to build VTK or ITK components. Instead, I passed the following options: > -DCTK_ENABLE_Python_Wrapping:BOOL=ON > -DCTK_ENABLE_DICOM:BOOL=ON > -DCTK_BUILD_EXAMPLES > > > > $ git clone git at github.com:commontk/CTK > > $ mkdir CTK-Debug > > $ cd CTK-Debug > > $ cmake > -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake > -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON > -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK > [...] > -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( > CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates > to True > -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 AND > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ > CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ > CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ CTK_ENABLE_DICOM:1 > AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ > CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True > -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt > -- Generated: > /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt > -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] > -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] > -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required by > [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] required > by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] > required by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] > required by [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_CommandLineModules/Core] required by > [ctkCommandLineModuleExplorer] > -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by > [ctkSimplePythonShell] > -- Enabling option [CTK_LIB_Scripting/Python/Core] required by > [ctkSimplePythonShell] > -- Found PythonInterp: /usr/bin/python (found version "2.7.4") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > version "2.7.4") > -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt > -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml > -- Found Git: /usr/bin/git (found version "1.8.1.2") > -- Configuring done > -- Generating done > -- Build files have been written to: /home/jchris/Projects/CTK-Debug > > $ make -j6 > [...] > [ 90%] Performing configure step for 'CTK-Configure' > [...] > -- Found PythonInterp: /usr/bin/python (found version "2.7.4") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > version "2.7.4") > -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt > -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml > -- Trying to find DCMTK expecting DCMTKConfig.cmake > -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed > -- Trying to find DCMTK relying on FindDCMTK.cmake > -- Looking for include file pthread.h > -- Looking fothe r include file pthread.h - found > -- Looking for pthread_create > -- Looking for pthread_create - not found > -- Looking for pthread_create in pthreads > -- Looking for pthread_create in pthreads - not found > -- Looking for pthread_create in pthread > -- Looking for pthread_create in pthread - found > -- Found Threads: TRUE > -- Found DCMTK: > /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config > > -- Trying to find DCMTK relying on FindDCMTK.cmake - ok > -- CTKCore: BFD support disabled > -- Configuring done > -- Generating done > [...] > -- Build files have been written to: > /home/jchris/Projects/CTK-Debug/CTK-build > > [...] > [100%] Built target CTKWidgetsCppTests > [100%] Built target CTK-build > > > > $ cd CTK-build > $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH > DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install > > Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is > explained by the fact the official DCMTK didn't integrate yet our latest > and greatest contribution [1] > > Hth > > Jc > > > [1] > https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 > > > > > > > > On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter > wrote: > > Hi all, > > > > I'm trying to build CTK separately, but I have problems with linking DCMTK. > > > > The way I build CTK: > > - Turn on CTK_BUILD_ALL > > - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and > test my changes in the CTK/Core/DICOM project) > > - Set the qmake executable > > - Configure > > - CMake complains about python paths, I set those manually > > - Configure, Generate > > - Build superbuild > > > > Then DCMTK is downloaded and built by the superbuild, but later on, CTK > projects find a completely different DCMTK directory (in my Slicer nightly > build directory). I tried to manually add the DCMTK directory to CMake, but > this variable does not exist in the superbuild (it is also not passed > down), and setting it to the inner CTK project doesn't work. > > > > Basically no matter what I do, the DCMTK path is set to whatever > find_project finds. This is what I found in CTKConfig.cmake: > > # Update CMake module path so that calling "find_package(DCMTK)" works as > expected > > # after calling "find_package(CTK)" > > # Ideally projects like DCMTK or PythonQt should provide both "Config" and > "Use" files. > > set(CMAKE_MODULE_PATH > > ${CTK_CMAKE_UTILITIES_DIR} > > ${CMAKE_MODULE_PATH} > > ) > > > > Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there > is no chance DCMTK is found correctly. > > > > Can someone please help with this? > > > > Thanks a lot, > > csaba > > > > ________________________________ > > Csaba Pinter > > Medical Software Systems Engineer > > Laboratory for Percutanous Surgery > > School of Computing > > Queen?s University > > Kingston, ON, Canada > > Email: csaba.pinter at queensu.ca > > Web: http://perk.cs.queensu.ca > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > > > > > -- > +1 919 869 8849 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Nov 4 16:12:12 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 4 Nov 2013 11:12:12 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Works for me. Could you create a Google event/hangout ? Talk to you tomorrow, Jc On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: > Hi Csaba - > > Andreas is here and working on some of the coding input from Julien (but > the emails to him from the CTK list aren't working right now for some > reason). > > -Steve > > > On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter wrote: > >> Hi Steve, >> >> >> >> Definitely, I can join the hangout tomorrow. Thanks for discussing the >> issue! >> >> >> >> Are the DKFZ fellas going to work on the list-based DICOM browser? We'd >> like to at least start integrating the display database and DICOM roles we >> implemented last time. >> >> >> >> Thanks, >> >> csaba >> >> >> >> >> >> *From:* Steve Pieper [mailto:pieper at ibility.net] >> *Sent:* November 4, 2013 10:02 >> *To:* Csaba Pinter >> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >> >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, Jc - >> >> >> >> London calling (always wanted to say that). We talked over the issue a >> bit and didn't see any obvious issues but there was a request from some >> folks for a further discussion of the underlying issue so we put it on the >> agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work >> for you two? >> >> >> >> Most of the work here this week so far is on CLI, XNAT/REST API, and >> DICOM. >> >> >> >> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >> >> >> >> -Steve >> >> >> >> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter >> wrote: >> >> Hi JC, >> >> >> >> Yes, it seems to have solved our CTK build problem. The reason I was >> asking about opinions is that I don't know what repercussions it may have >> on other platforms. >> >> If it seems OK the I'd appreciate propagating it to the CTK core or ITK. >> I can create a CTK topic branch containing the change if it makes the >> process easier. >> >> >> >> Thanks, >> >> csaba >> >> >> >> >> >> *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] >> >> *Sent:* November 4, 2013 09:30 >> *To:* Csaba Pinter >> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >> >> >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Based on your entry in the CTK tracker. I am assuming it is good to go ? >> See https://github.com/commontk/CTK/issues/382 >> >> >> >> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >> jchris.fillionr at kitware.com> wrote: >> >> Hi Csaba, >> >> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >> coordinate with ITK folks so that they also update their FindDCMTK.cmake >> file. >> >> Thanks >> >> Jc >> >> >> [1] >> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >> >> >> >> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter >> wrote: >> >> Hi Steve, >> >> >> >> I was going to do just that, thanks for the reminder! >> >> I created issue https://github.com/commontk/CTK/issues/382. >> >> The main reason I haven't created a topic branch yet is that I would like >> to hear some opinions about it first, as I don't know what consequences it >> has on Linux and Mac. >> >> >> >> FYI my agenda for next week besides this small change is to try our >> display tables and DICOM roles enhancement for the DICOM browser (that >> Andras and I implemented during the last hackfest) against the latest >> listview-based browser and integrate it if it turns out to be working fine. >> >> >> >> Thanks, >> >> csaba >> >> >> >> >> >> *From:* Steve Pieper [mailto:pieper at ibility.net] >> *Sent:* October 31, 2013 16:37 >> >> >> *To:* Csaba Pinter >> *Cc:* CTK mailing list >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba - >> >> >> >> We'll be discussing open issues next week in London - can you make sure >> there's a ctk issue that points to your assembla report? >> >> >> >> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >> >> >> >> Thanks, >> >> Steve >> >> >> >> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter >> wrote: >> >> Hi there, >> >> >> >> Any thoughts about the FindDCMTK changes proposed below? >> >> I'd appreciate any feedback. >> >> >> >> Thanks, >> >> csaba >> >> >> >> >> >> *From:* ctk-developers-bounces at commontk.org [mailto: >> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >> *Sent:* October 10, 2013 15:14 >> *To:* CTK mailing list >> >> >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hello, >> >> >> >> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I >> could successfully build CTK with DCMTK. >> >> >> >> As we have the same issue from time to time with CTK in Slicer (but >> finally we could reproduce it, see [1]), I propose adding this flag to >> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >> change is not integrated to DCMTK. >> >> As my CMake knowledge is limited, I don't know if this change causes any >> problem on other operating systems though. >> >> >> >> I'd appreciate to hear your opinions about this. >> >> >> >> Thank you, >> >> csaba >> >> >> >> [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >> >> >> >> >> >> *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] >> >> *Sent:* October 4, 2013 18:34 >> *To:* Csaba Pinter >> *Cc:* Andras Lasso; CTK mailing list >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, >> >> >> >> As illustrated in the enclosed screenshot, build tree can be exported >> into the CMake package registry. As some point, the DCMTK build tree has >> probably been exported [1][2][3]. >> >> Since when building CTK, it is expected that there are no >> DCMTKConfig.cmake available, the first should be failing. In your case, it >> seems not to be failing because it resolves to that previous build added to >> the registery. >> >> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the >> FindDCMTK.cmake module available in CTK. See [4] >> >> >> >> Hth >> >> Jc >> >> >> >> [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >> [2] >> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >> >> [3] >> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >> >> [4] >> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >> >> >> >> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter >> wrote: >> >> Hi Jc, >> >> >> >> I tried building CTK in many ways, but the result is always the same, so >> the problem is completely reproducible, at least on my computer (I haven't >> tried it elsewhere yet, but I plan to). As we have been struggling with >> this issue for quite a while, but haven't been able to consistently >> reproduce it, this is a great opportunity to fix it once and for all. >> >> >> >> I did some digging and this is what I found: >> >> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the >> incorrect directory that is used later (in one of my slicer builds) >> >> - The reason why the DCMTK downloaded by the superbuild is not >> found is most probably that it is a version that doesn't have >> DCMTKConfig.cmake (as you described earlier) >> >> - The same thing (finding the wrong DCMTK) happens if I add >> NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >> >> >> >> Now I don't have any idea how to get the superbuild to use its own DCMTK. >> >> Also even if I can do a workaround and have a good build of CTK on my >> machine, this is an issue that other people who want to build CTK on >> Windows while already having a Slicer build have to face. >> >> >> >> Cheers, >> >> csaba >> >> >> >> >> >> *From:* Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] >> >> *Sent:* October 4, 2013 12:07 >> *To:* Andras Lasso >> *Cc:* Csaba Pinter; CTK mailing list >> >> >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, Andras, >> >> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >> suggest to add the NO_CMAKE_BUILDS_PATH ? >> >> Let's also note that the FindDCMTK.cmake provided by ITK would have to >> patched also ... >> >> If you can reproduce the problem, with a combination of clearing cache + >> adding some "message()" statement, you should be able to find out or >> confirm what is the source of the problem. >> >> >> >> Jc >> >> >> [1] >> >> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >> >> >> >> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: >> >> I have this annoying issue during Slicer builds as well: my nightly >> slicer builds usually break after a few days because after I configure >> other projects in CMake CTK finds DCMTK of another project instead of its >> own. >> >> >> >> It may be due to the find_package path finding rule 5: ?Search project >> build trees recently configured in a CMake GUI. This can be skipped if >> NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is >> building multiple dependent projects one after another.? ( >> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should >> rely on rules 1-4 or disable rule 5 ? or it may be possible that something >> else goes wrong and that?s why the rule 5 kicks in. >> >> >> >> Andras >> >> >> >> >> >> *From:* ctk-developers-bounces at commontk.org [mailto: >> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >> Fillion-Robin >> *Sent:* Wednesday, October 02, 2013 11:39 AM >> >> >> *To:* Csaba Pinter >> *Cc:* CTK mailing list >> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >> >> >> >> Hi Csaba, >> >> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable >> that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" >> should not be empty as illustrated below: >> >> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >> SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") >> >> >> >> >> >> Otherwise, you will find below the result of my experiment. When >> configured, CTK found the expected DCMTK. >> >> >> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >> "python2.7-dev" doing so the following works. >> >> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system >> to build VTK or ITK components. Instead, I passed the following options: >> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >> -DCTK_ENABLE_DICOM:BOOL=ON >> -DCTK_BUILD_EXAMPLES >> >> >> >> $ git clone git at github.com:commontk/CTK >> >> $ mkdir CTK-Debug >> >> $ cd CTK-Debug >> >> $ cmake >> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >> [...] >> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( >> CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates >> to True >> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 >> AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >> CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >> -- Generated: >> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required >> by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >> required by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >> required by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] >> required by [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >> [ctkCommandLineModuleExplorer] >> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >> [ctkSimplePythonShell] >> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >> [ctkSimplePythonShell] >> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >> version "2.7.4") >> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >> -- Found Git: /usr/bin/git (found version "1.8.1.2") >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >> >> $ make -j6 >> [...] >> [ 90%] Performing configure step for 'CTK-Configure' >> [...] >> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >> version "2.7.4") >> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >> -- Trying to find DCMTK expecting DCMTKConfig.cmake >> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >> -- Trying to find DCMTK relying on FindDCMTK.cmake >> -- Looking for include file pthread.h >> -- Looking fothe r include file pthread.h - found >> -- Looking for pthread_create >> -- Looking for pthread_create - not found >> -- Looking for pthread_create in pthreads >> -- Looking for pthread_create in pthreads - not found >> -- Looking for pthread_create in pthread >> -- Looking for pthread_create in pthread - found >> -- Found Threads: TRUE >> -- Found DCMTK: >> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >> >> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >> -- CTKCore: BFD support disabled >> -- Configuring done >> -- Generating done >> [...] >> -- Build files have been written to: >> /home/jchris/Projects/CTK-Debug/CTK-build >> >> [...] >> [100%] Built target CTKWidgetsCppTests >> [100%] Built target CTK-build >> >> >> >> $ cd CTK-build >> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >> >> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is >> explained by the fact the official DCMTK didn't integrate yet our latest >> and greatest contribution [1] >> >> Hth >> >> Jc >> >> >> [1] >> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >> >> >> >> >> >> >> >> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter >> wrote: >> >> Hi all, >> >> >> >> I'm trying to build CTK separately, but I have problems with linking >> DCMTK. >> >> >> >> The way I build CTK: >> >> - Turn on CTK_BUILD_ALL >> >> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and >> test my changes in the CTK/Core/DICOM project) >> >> - Set the qmake executable >> >> - Configure >> >> - CMake complains about python paths, I set those manually >> >> - Configure, Generate >> >> - Build superbuild >> >> >> >> Then DCMTK is downloaded and built by the superbuild, but later on, CTK >> projects find a completely different DCMTK directory (in my Slicer nightly >> build directory). I tried to manually add the DCMTK directory to CMake, but >> this variable does not exist in the superbuild (it is also not passed >> down), and setting it to the inner CTK project doesn't work. >> >> >> >> Basically no matter what I do, the DCMTK path is set to whatever >> find_project finds. This is what I found in CTKConfig.cmake: >> >> # Update CMake module path so that calling "find_package(DCMTK)" works as >> expected >> >> # after calling "find_package(CTK)" >> >> # Ideally projects like DCMTK or PythonQt should provide both "Config" >> and "Use" files. >> >> set(CMAKE_MODULE_PATH >> >> ${CTK_CMAKE_UTILITIES_DIR} >> >> ${CMAKE_MODULE_PATH} >> >> ) >> >> >> >> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there >> is no chance DCMTK is found correctly. >> >> >> >> Can someone please help with this? >> >> >> >> Thanks a lot, >> >> csaba >> >> >> >> ________________________________ >> >> Csaba Pinter >> >> Medical Software Systems Engineer >> >> Laboratory for Percutanous Surgery >> >> School of Computing >> >> Queen?s University >> >> Kingston, ON, Canada >> >> Email: csaba.pinter at queensu.ca >> >> Web: http://perk.cs.queensu.ca >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you >> in error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> >> >> -- >> +1 919 869 8849 >> >> >> > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 4 16:16:43 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 4 Nov 2013 11:16:43 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: I was planning to just start the hangout and then email the link - do you find that scheduling the event has advantages? Wouldn't we need a ctk google group or something? Talk to you tomorrow, -Steve On Mon, Nov 4, 2013 at 11:12 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Works for me. Could you create a Google event/hangout ? > Talk to you tomorrow, > Jc > > > On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: > >> Hi Csaba - >> >> Andreas is here and working on some of the coding input from Julien (but >> the emails to him from the CTK list aren't working right now for some >> reason). >> >> -Steve >> >> >> On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter wrote: >> >>> Hi Steve, >>> >>> >>> >>> Definitely, I can join the hangout tomorrow. Thanks for discussing the >>> issue! >>> >>> >>> >>> Are the DKFZ fellas going to work on the list-based DICOM browser? We'd >>> like to at least start integrating the display database and DICOM roles we >>> implemented last time. >>> >>> >>> >>> Thanks, >>> >>> csaba >>> >>> >>> >>> >>> >>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>> *Sent:* November 4, 2013 10:02 >>> *To:* Csaba Pinter >>> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >>> >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Hi Csaba, Jc - >>> >>> >>> >>> London calling (always wanted to say that). We talked over the issue a >>> bit and didn't see any obvious issues but there was a request from some >>> folks for a further discussion of the underlying issue so we put it on the >>> agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work >>> for you two? >>> >>> >>> >>> Most of the work here this week so far is on CLI, XNAT/REST API, and >>> DICOM. >>> >>> >>> >>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >>> >>> >>> >>> -Steve >>> >>> >>> >>> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter >>> wrote: >>> >>> Hi JC, >>> >>> >>> >>> Yes, it seems to have solved our CTK build problem. The reason I was >>> asking about opinions is that I don't know what repercussions it may have >>> on other platforms. >>> >>> If it seems OK the I'd appreciate propagating it to the CTK core or ITK. >>> I can create a CTK topic branch containing the change if it makes the >>> process easier. >>> >>> >>> >>> Thanks, >>> >>> csaba >>> >>> >>> >>> >>> >>> *From:* Jean-Christophe Fillion-Robin [mailto: >>> jchris.fillionr at kitware.com] >>> *Sent:* November 4, 2013 09:30 >>> *To:* Csaba Pinter >>> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >>> >>> >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Based on your entry in the CTK tracker. I am assuming it is good to go ? >>> See https://github.com/commontk/CTK/issues/382 >>> >>> >>> >>> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >>> jchris.fillionr at kitware.com> wrote: >>> >>> Hi Csaba, >>> >>> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >>> coordinate with ITK folks so that they also update their FindDCMTK.cmake >>> file. >>> >>> Thanks >>> >>> Jc >>> >>> >>> [1] >>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>> >>> >>> >>> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter >>> wrote: >>> >>> Hi Steve, >>> >>> >>> >>> I was going to do just that, thanks for the reminder! >>> >>> I created issue https://github.com/commontk/CTK/issues/382. >>> >>> The main reason I haven't created a topic branch yet is that I would >>> like to hear some opinions about it first, as I don't know what >>> consequences it has on Linux and Mac. >>> >>> >>> >>> FYI my agenda for next week besides this small change is to try our >>> display tables and DICOM roles enhancement for the DICOM browser (that >>> Andras and I implemented during the last hackfest) against the latest >>> listview-based browser and integrate it if it turns out to be working fine. >>> >>> >>> >>> Thanks, >>> >>> csaba >>> >>> >>> >>> >>> >>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>> *Sent:* October 31, 2013 16:37 >>> >>> >>> *To:* Csaba Pinter >>> *Cc:* CTK mailing list >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Hi Csaba - >>> >>> >>> >>> We'll be discussing open issues next week in London - can you make sure >>> there's a ctk issue that points to your assembla report? >>> >>> >>> >>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >>> >>> >>> >>> Thanks, >>> >>> Steve >>> >>> >>> >>> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter >>> wrote: >>> >>> Hi there, >>> >>> >>> >>> Any thoughts about the FindDCMTK changes proposed below? >>> >>> I'd appreciate any feedback. >>> >>> >>> >>> Thanks, >>> >>> csaba >>> >>> >>> >>> >>> >>> *From:* ctk-developers-bounces at commontk.org [mailto: >>> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >>> *Sent:* October 10, 2013 15:14 >>> *To:* CTK mailing list >>> >>> >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Hello, >>> >>> >>> >>> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now >>> I could successfully build CTK with DCMTK. >>> >>> >>> >>> As we have the same issue from time to time with CTK in Slicer (but >>> finally we could reproduce it, see [1]), I propose adding this flag to >>> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >>> change is not integrated to DCMTK. >>> >>> As my CMake knowledge is limited, I don't know if this change causes any >>> problem on other operating systems though. >>> >>> >>> >>> I'd appreciate to hear your opinions about this. >>> >>> >>> >>> Thank you, >>> >>> csaba >>> >>> >>> >>> [1] >>> https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >>> >>> >>> >>> >>> >>> *From:* Jean-Christophe Fillion-Robin [ >>> mailto:jchris.fillionr at kitware.com ] >>> *Sent:* October 4, 2013 18:34 >>> *To:* Csaba Pinter >>> *Cc:* Andras Lasso; CTK mailing list >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Hi Csaba, >>> >>> >>> >>> As illustrated in the enclosed screenshot, build tree can be exported >>> into the CMake package registry. As some point, the DCMTK build tree has >>> probably been exported [1][2][3]. >>> >>> Since when building CTK, it is expected that there are no >>> DCMTKConfig.cmake available, the first should be failing. In your case, it >>> seems not to be failing because it resolves to that previous build added to >>> the registery. >>> >>> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the >>> FindDCMTK.cmake module available in CTK. See [4] >>> >>> >>> >>> Hth >>> >>> Jc >>> >>> >>> >>> [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >>> [2] >>> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >>> >>> [3] >>> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >>> >>> [4] >>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>> >>> >>> >>> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter >>> wrote: >>> >>> Hi Jc, >>> >>> >>> >>> I tried building CTK in many ways, but the result is always the same, so >>> the problem is completely reproducible, at least on my computer (I haven't >>> tried it elsewhere yet, but I plan to). As we have been struggling with >>> this issue for quite a while, but haven't been able to consistently >>> reproduce it, this is a great opportunity to fix it once and for all. >>> >>> >>> >>> I did some digging and this is what I found: >>> >>> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the >>> incorrect directory that is used later (in one of my slicer builds) >>> >>> - The reason why the DCMTK downloaded by the superbuild is not >>> found is most probably that it is a version that doesn't have >>> DCMTKConfig.cmake (as you described earlier) >>> >>> - The same thing (finding the wrong DCMTK) happens if I add >>> NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >>> >>> >>> >>> Now I don't have any idea how to get the superbuild to use its own DCMTK. >>> >>> Also even if I can do a workaround and have a good build of CTK on my >>> machine, this is an issue that other people who want to build CTK on >>> Windows while already having a Slicer build have to face. >>> >>> >>> >>> Cheers, >>> >>> csaba >>> >>> >>> >>> >>> >>> *From:* Jean-Christophe Fillion-Robin [mailto: >>> jchris.fillionr at kitware.com] >>> *Sent:* October 4, 2013 12:07 >>> *To:* Andras Lasso >>> *Cc:* Csaba Pinter; CTK mailing list >>> >>> >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Hi Csaba, Andras, >>> >>> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >>> suggest to add the NO_CMAKE_BUILDS_PATH ? >>> >>> Let's also note that the FindDCMTK.cmake provided by ITK would have to >>> patched also ... >>> >>> If you can reproduce the problem, with a combination of clearing cache + >>> adding some "message()" statement, you should be able to find out or >>> confirm what is the source of the problem. >>> >>> >>> >>> Jc >>> >>> >>> [1] >>> >>> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >>> >>> >>> >>> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: >>> >>> I have this annoying issue during Slicer builds as well: my nightly >>> slicer builds usually break after a few days because after I configure >>> other projects in CMake CTK finds DCMTK of another project instead of its >>> own. >>> >>> >>> >>> It may be due to the find_package path finding rule 5: ?Search project >>> build trees recently configured in a CMake GUI. This can be skipped if >>> NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is >>> building multiple dependent projects one after another.? ( >>> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK >>> should rely on rules 1-4 or disable rule 5 ? or it may be possible that >>> something else goes wrong and that?s why the rule 5 kicks in. >>> >>> >>> >>> Andras >>> >>> >>> >>> >>> >>> *From:* ctk-developers-bounces at commontk.org [mailto: >>> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >>> Fillion-Robin >>> *Sent:* Wednesday, October 02, 2013 11:39 AM >>> >>> >>> *To:* Csaba Pinter >>> *Cc:* CTK mailing list >>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>> >>> >>> >>> Hi Csaba, >>> >>> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global >>> variable that is empty by default. On the other hand >>> "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: >>> >>> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >>> SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") >>> >>> >>> >>> >>> >>> Otherwise, you will find below the result of my experiment. When >>> configured, CTK found the expected DCMTK. >>> >>> >>> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >>> "python2.7-dev" doing so the following works. >>> >>> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system >>> to build VTK or ITK components. Instead, I passed the following options: >>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >>> -DCTK_ENABLE_DICOM:BOOL=ON >>> -DCTK_BUILD_EXAMPLES >>> >>> >>> >>> $ git clone git at github.com:commontk/CTK >>> >>> $ mkdir CTK-Debug >>> >>> $ cd CTK-Debug >>> >>> $ cmake >>> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >>> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >>> [...] >>> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( >>> CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates >>> to True >>> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >>> CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >>> CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 >>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 >>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND >>> CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 >>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >>> CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >>> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >>> -- Generated: >>> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >>> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >>> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required >>> by [ctkCommandLineModuleExplorer] >>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >>> required by [ctkCommandLineModuleExplorer] >>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >>> required by [ctkCommandLineModuleExplorer] >>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] >>> required by [ctkCommandLineModuleExplorer] >>> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >>> [ctkCommandLineModuleExplorer] >>> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >>> [ctkSimplePythonShell] >>> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >>> [ctkSimplePythonShell] >>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >>> version "2.7.4") >>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >>> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >>> -- Found Git: /usr/bin/git (found version "1.8.1.2") >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >>> >>> $ make -j6 >>> [...] >>> [ 90%] Performing configure step for 'CTK-Configure' >>> [...] >>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >>> version "2.7.4") >>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >>> -- Trying to find DCMTK expecting DCMTKConfig.cmake >>> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >>> -- Trying to find DCMTK relying on FindDCMTK.cmake >>> -- Looking for include file pthread.h >>> -- Looking fothe r include file pthread.h - found >>> -- Looking for pthread_create >>> -- Looking for pthread_create - not found >>> -- Looking for pthread_create in pthreads >>> -- Looking for pthread_create in pthreads - not found >>> -- Looking for pthread_create in pthread >>> -- Looking for pthread_create in pthread - found >>> -- Found Threads: TRUE >>> -- Found DCMTK: >>> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >>> >>> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >>> -- CTKCore: BFD support disabled >>> -- Configuring done >>> -- Generating done >>> [...] >>> -- Build files have been written to: >>> /home/jchris/Projects/CTK-Debug/CTK-build >>> >>> [...] >>> [100%] Built target CTKWidgetsCppTests >>> [100%] Built target CTK-build >>> >>> >>> >>> $ cd CTK-build >>> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >>> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >>> >>> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is >>> explained by the fact the official DCMTK didn't integrate yet our latest >>> and greatest contribution [1] >>> >>> Hth >>> >>> Jc >>> >>> >>> [1] >>> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter >>> wrote: >>> >>> Hi all, >>> >>> >>> >>> I'm trying to build CTK separately, but I have problems with linking >>> DCMTK. >>> >>> >>> >>> The way I build CTK: >>> >>> - Turn on CTK_BUILD_ALL >>> >>> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and >>> test my changes in the CTK/Core/DICOM project) >>> >>> - Set the qmake executable >>> >>> - Configure >>> >>> - CMake complains about python paths, I set those manually >>> >>> - Configure, Generate >>> >>> - Build superbuild >>> >>> >>> >>> Then DCMTK is downloaded and built by the superbuild, but later on, CTK >>> projects find a completely different DCMTK directory (in my Slicer nightly >>> build directory). I tried to manually add the DCMTK directory to CMake, but >>> this variable does not exist in the superbuild (it is also not passed >>> down), and setting it to the inner CTK project doesn't work. >>> >>> >>> >>> Basically no matter what I do, the DCMTK path is set to whatever >>> find_project finds. This is what I found in CTKConfig.cmake: >>> >>> # Update CMake module path so that calling "find_package(DCMTK)" works >>> as expected >>> >>> # after calling "find_package(CTK)" >>> >>> # Ideally projects like DCMTK or PythonQt should provide both "Config" >>> and "Use" files. >>> >>> set(CMAKE_MODULE_PATH >>> >>> ${CTK_CMAKE_UTILITIES_DIR} >>> >>> ${CMAKE_MODULE_PATH} >>> >>> ) >>> >>> >>> >>> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so >>> there is no chance DCMTK is found correctly. >>> >>> >>> >>> Can someone please help with this? >>> >>> >>> >>> Thanks a lot, >>> >>> csaba >>> >>> >>> >>> ________________________________ >>> >>> Csaba Pinter >>> >>> Medical Software Systems Engineer >>> >>> Laboratory for Percutanous Surgery >>> >>> School of Computing >>> >>> Queen?s University >>> >>> Kingston, ON, Canada >>> >>> Email: csaba.pinter at queensu.ca >>> >>> Web: http://perk.cs.queensu.ca >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >>> The information in this e-mail is intended only for the person to whom >>> it is >>> addressed. If you believe this e-mail was sent to you in error and the >>> e-mail >>> contains patient information, please contact the Partners Compliance >>> HelpLine at >>> http://www.partners.org/complianceline . If the e-mail was sent to you >>> in error >>> but does not contain patient information, please contact the sender and >>> properly >>> dispose of the e-mail. >>> >>> >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >>> >>> >> >> > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Nov 4 16:18:24 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 4 Nov 2013 11:18:24 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Creating the event on G+ automatically add it to my calendar :) May be we could create a CommonTK Google plus community ? On Mon, Nov 4, 2013 at 11:16 AM, Steve Pieper wrote: > I was planning to just start the hangout and then email the link - do you > find that scheduling the event has advantages? Wouldn't we need a ctk > google group or something? > > Talk to you tomorrow, > -Steve > > > On Mon, Nov 4, 2013 at 11:12 AM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> Works for me. Could you create a Google event/hangout ? >> Talk to you tomorrow, >> Jc >> >> >> On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: >> >>> Hi Csaba - >>> >>> Andreas is here and working on some of the coding input from Julien (but >>> the emails to him from the CTK list aren't working right now for some >>> reason). >>> >>> -Steve >>> >>> >>> On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter wrote: >>> >>>> Hi Steve, >>>> >>>> >>>> >>>> Definitely, I can join the hangout tomorrow. Thanks for discussing the >>>> issue! >>>> >>>> >>>> >>>> Are the DKFZ fellas going to work on the list-based DICOM browser? We'd >>>> like to at least start integrating the display database and DICOM roles we >>>> implemented last time. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> csaba >>>> >>>> >>>> >>>> >>>> >>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>> *Sent:* November 4, 2013 10:02 >>>> *To:* Csaba Pinter >>>> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >>>> >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Hi Csaba, Jc - >>>> >>>> >>>> >>>> London calling (always wanted to say that). We talked over the issue a >>>> bit and didn't see any obvious issues but there was a request from some >>>> folks for a further discussion of the underlying issue so we put it on the >>>> agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work >>>> for you two? >>>> >>>> >>>> >>>> Most of the work here this week so far is on CLI, XNAT/REST API, and >>>> DICOM. >>>> >>>> >>>> >>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >>>> >>>> >>>> >>>> -Steve >>>> >>>> >>>> >>>> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter >>>> wrote: >>>> >>>> Hi JC, >>>> >>>> >>>> >>>> Yes, it seems to have solved our CTK build problem. The reason I was >>>> asking about opinions is that I don't know what repercussions it may have >>>> on other platforms. >>>> >>>> If it seems OK the I'd appreciate propagating it to the CTK core or >>>> ITK. I can create a CTK topic branch containing the change if it makes the >>>> process easier. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> csaba >>>> >>>> >>>> >>>> >>>> >>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>> jchris.fillionr at kitware.com] >>>> *Sent:* November 4, 2013 09:30 >>>> *To:* Csaba Pinter >>>> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >>>> >>>> >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Based on your entry in the CTK tracker. I am assuming it is good to go >>>> ? >>>> See https://github.com/commontk/CTK/issues/382 >>>> >>>> >>>> >>>> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >>>> jchris.fillionr at kitware.com> wrote: >>>> >>>> Hi Csaba, >>>> >>>> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >>>> coordinate with ITK folks so that they also update their FindDCMTK.cmake >>>> file. >>>> >>>> Thanks >>>> >>>> Jc >>>> >>>> >>>> [1] >>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>> >>>> >>>> >>>> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter >>>> wrote: >>>> >>>> Hi Steve, >>>> >>>> >>>> >>>> I was going to do just that, thanks for the reminder! >>>> >>>> I created issue https://github.com/commontk/CTK/issues/382. >>>> >>>> The main reason I haven't created a topic branch yet is that I would >>>> like to hear some opinions about it first, as I don't know what >>>> consequences it has on Linux and Mac. >>>> >>>> >>>> >>>> FYI my agenda for next week besides this small change is to try our >>>> display tables and DICOM roles enhancement for the DICOM browser (that >>>> Andras and I implemented during the last hackfest) against the latest >>>> listview-based browser and integrate it if it turns out to be working fine. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> csaba >>>> >>>> >>>> >>>> >>>> >>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>> *Sent:* October 31, 2013 16:37 >>>> >>>> >>>> *To:* Csaba Pinter >>>> *Cc:* CTK mailing list >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Hi Csaba - >>>> >>>> >>>> >>>> We'll be discussing open issues next week in London - can you make sure >>>> there's a ctk issue that points to your assembla report? >>>> >>>> >>>> >>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Steve >>>> >>>> >>>> >>>> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter >>>> wrote: >>>> >>>> Hi there, >>>> >>>> >>>> >>>> Any thoughts about the FindDCMTK changes proposed below? >>>> >>>> I'd appreciate any feedback. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> csaba >>>> >>>> >>>> >>>> >>>> >>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >>>> *Sent:* October 10, 2013 15:14 >>>> *To:* CTK mailing list >>>> >>>> >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now >>>> I could successfully build CTK with DCMTK. >>>> >>>> >>>> >>>> As we have the same issue from time to time with CTK in Slicer (but >>>> finally we could reproduce it, see [1]), I propose adding this flag to >>>> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >>>> change is not integrated to DCMTK. >>>> >>>> As my CMake knowledge is limited, I don't know if this change causes >>>> any problem on other operating systems though. >>>> >>>> >>>> >>>> I'd appreciate to hear your opinions about this. >>>> >>>> >>>> >>>> Thank you, >>>> >>>> csaba >>>> >>>> >>>> >>>> [1] >>>> https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >>>> >>>> >>>> >>>> >>>> >>>> *From:* Jean-Christophe Fillion-Robin [ >>>> mailto:jchris.fillionr at kitware.com ] >>>> *Sent:* October 4, 2013 18:34 >>>> *To:* Csaba Pinter >>>> *Cc:* Andras Lasso; CTK mailing list >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Hi Csaba, >>>> >>>> >>>> >>>> As illustrated in the enclosed screenshot, build tree can be exported >>>> into the CMake package registry. As some point, the DCMTK build tree has >>>> probably been exported [1][2][3]. >>>> >>>> Since when building CTK, it is expected that there are no >>>> DCMTKConfig.cmake available, the first should be failing. In your case, it >>>> seems not to be failing because it resolves to that previous build added to >>>> the registery. >>>> >>>> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the >>>> FindDCMTK.cmake module available in CTK. See [4] >>>> >>>> >>>> >>>> Hth >>>> >>>> Jc >>>> >>>> >>>> >>>> [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >>>> [2] >>>> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >>>> >>>> [3] >>>> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >>>> >>>> [4] >>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>> >>>> >>>> >>>> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter >>>> wrote: >>>> >>>> Hi Jc, >>>> >>>> >>>> >>>> I tried building CTK in many ways, but the result is always the same, >>>> so the problem is completely reproducible, at least on my computer (I >>>> haven't tried it elsewhere yet, but I plan to). As we have been struggling >>>> with this issue for quite a while, but haven't been able to consistently >>>> reproduce it, this is a great opportunity to fix it once and for all. >>>> >>>> >>>> >>>> I did some digging and this is what I found: >>>> >>>> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the >>>> incorrect directory that is used later (in one of my slicer builds) >>>> >>>> - The reason why the DCMTK downloaded by the superbuild is >>>> not found is most probably that it is a version that doesn't have >>>> DCMTKConfig.cmake (as you described earlier) >>>> >>>> - The same thing (finding the wrong DCMTK) happens if I add >>>> NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >>>> >>>> >>>> >>>> Now I don't have any idea how to get the superbuild to use its own >>>> DCMTK. >>>> >>>> Also even if I can do a workaround and have a good build of CTK on my >>>> machine, this is an issue that other people who want to build CTK on >>>> Windows while already having a Slicer build have to face. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> csaba >>>> >>>> >>>> >>>> >>>> >>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>> jchris.fillionr at kitware.com] >>>> *Sent:* October 4, 2013 12:07 >>>> *To:* Andras Lasso >>>> *Cc:* Csaba Pinter; CTK mailing list >>>> >>>> >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Hi Csaba, Andras, >>>> >>>> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >>>> suggest to add the NO_CMAKE_BUILDS_PATH ? >>>> >>>> Let's also note that the FindDCMTK.cmake provided by ITK would have to >>>> patched also ... >>>> >>>> If you can reproduce the problem, with a combination of clearing cache >>>> + adding some "message()" statement, you should be able to find out or >>>> confirm what is the source of the problem. >>>> >>>> >>>> >>>> Jc >>>> >>>> >>>> [1] >>>> >>>> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >>>> >>>> >>>> >>>> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: >>>> >>>> I have this annoying issue during Slicer builds as well: my nightly >>>> slicer builds usually break after a few days because after I configure >>>> other projects in CMake CTK finds DCMTK of another project instead of its >>>> own. >>>> >>>> >>>> >>>> It may be due to the find_package path finding rule 5: ?Search project >>>> build trees recently configured in a CMake GUI. This can be skipped if >>>> NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is >>>> building multiple dependent projects one after another.? ( >>>> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK >>>> should rely on rules 1-4 or disable rule 5 ? or it may be possible that >>>> something else goes wrong and that?s why the rule 5 kicks in. >>>> >>>> >>>> >>>> Andras >>>> >>>> >>>> >>>> >>>> >>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >>>> Fillion-Robin >>>> *Sent:* Wednesday, October 02, 2013 11:39 AM >>>> >>>> >>>> *To:* Csaba Pinter >>>> *Cc:* CTK mailing list >>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>> >>>> >>>> >>>> Hi Csaba, >>>> >>>> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global >>>> variable that is empty by default. On the other hand >>>> "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: >>>> >>>> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >>>> SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") >>>> >>>> >>>> >>>> >>>> >>>> Otherwise, you will find below the result of my experiment. When >>>> configured, CTK found the expected DCMTK. >>>> >>>> >>>> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >>>> "python2.7-dev" doing so the following works. >>>> >>>> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build >>>> system to build VTK or ITK components. Instead, I passed the following >>>> options: >>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >>>> -DCTK_ENABLE_DICOM:BOOL=ON >>>> -DCTK_BUILD_EXAMPLES >>>> >>>> >>>> >>>> $ git clone git at github.com:commontk/CTK >>>> >>>> $ mkdir CTK-Debug >>>> >>>> $ cd CTK-Debug >>>> >>>> $ cmake >>>> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >>>> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >>>> [...] >>>> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( >>>> CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates >>>> to True >>>> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 >>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 >>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND >>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 >>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >>>> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >>>> -- Generated: >>>> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >>>> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >>>> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required >>>> by [ctkCommandLineModuleExplorer] >>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >>>> required by [ctkCommandLineModuleExplorer] >>>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >>>> required by [ctkCommandLineModuleExplorer] >>>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] >>>> required by [ctkCommandLineModuleExplorer] >>>> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >>>> [ctkCommandLineModuleExplorer] >>>> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >>>> [ctkSimplePythonShell] >>>> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >>>> [ctkSimplePythonShell] >>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >>>> version "2.7.4") >>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >>>> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >>>> -- Found Git: /usr/bin/git (found version "1.8.1.2") >>>> -- Configuring done >>>> -- Generating done >>>> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >>>> >>>> $ make -j6 >>>> [...] >>>> [ 90%] Performing configure step for 'CTK-Configure' >>>> [...] >>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >>>> version "2.7.4") >>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake >>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >>>> -- Trying to find DCMTK relying on FindDCMTK.cmake >>>> -- Looking for include file pthread.h >>>> -- Looking fothe r include file pthread.h - found >>>> -- Looking for pthread_create >>>> -- Looking for pthread_create - not found >>>> -- Looking for pthread_create in pthreads >>>> -- Looking for pthread_create in pthreads - not found >>>> -- Looking for pthread_create in pthread >>>> -- Looking for pthread_create in pthread - found >>>> -- Found Threads: TRUE >>>> -- Found DCMTK: >>>> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >>>> >>>> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >>>> -- CTKCore: BFD support disabled >>>> -- Configuring done >>>> -- Generating done >>>> [...] >>>> -- Build files have been written to: >>>> /home/jchris/Projects/CTK-Debug/CTK-build >>>> >>>> [...] >>>> [100%] Built target CTKWidgetsCppTests >>>> [100%] Built target CTK-build >>>> >>>> >>>> >>>> $ cd CTK-build >>>> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >>>> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >>>> >>>> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this >>>> is explained by the fact the official DCMTK didn't integrate yet our latest >>>> and greatest contribution [1] >>>> >>>> Hth >>>> >>>> Jc >>>> >>>> >>>> [1] >>>> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter >>>> wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> I'm trying to build CTK separately, but I have problems with linking >>>> DCMTK. >>>> >>>> >>>> >>>> The way I build CTK: >>>> >>>> - Turn on CTK_BUILD_ALL >>>> >>>> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge >>>> and test my changes in the CTK/Core/DICOM project) >>>> >>>> - Set the qmake executable >>>> >>>> - Configure >>>> >>>> - CMake complains about python paths, I set those manually >>>> >>>> - Configure, Generate >>>> >>>> - Build superbuild >>>> >>>> >>>> >>>> Then DCMTK is downloaded and built by the superbuild, but later on, CTK >>>> projects find a completely different DCMTK directory (in my Slicer nightly >>>> build directory). I tried to manually add the DCMTK directory to CMake, but >>>> this variable does not exist in the superbuild (it is also not passed >>>> down), and setting it to the inner CTK project doesn't work. >>>> >>>> >>>> >>>> Basically no matter what I do, the DCMTK path is set to whatever >>>> find_project finds. This is what I found in CTKConfig.cmake: >>>> >>>> # Update CMake module path so that calling "find_package(DCMTK)" works >>>> as expected >>>> >>>> # after calling "find_package(CTK)" >>>> >>>> # Ideally projects like DCMTK or PythonQt should provide both "Config" >>>> and "Use" files. >>>> >>>> set(CMAKE_MODULE_PATH >>>> >>>> ${CTK_CMAKE_UTILITIES_DIR} >>>> >>>> ${CMAKE_MODULE_PATH} >>>> >>>> ) >>>> >>>> >>>> >>>> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so >>>> there is no chance DCMTK is found correctly. >>>> >>>> >>>> >>>> Can someone please help with this? >>>> >>>> >>>> >>>> Thanks a lot, >>>> >>>> csaba >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> Csaba Pinter >>>> >>>> Medical Software Systems Engineer >>>> >>>> Laboratory for Percutanous Surgery >>>> >>>> School of Computing >>>> >>>> Queen?s University >>>> >>>> Kingston, ON, Canada >>>> >>>> Email: csaba.pinter at queensu.ca >>>> >>>> Web: http://perk.cs.queensu.ca >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>>> The information in this e-mail is intended only for the person to whom >>>> it is >>>> addressed. If you believe this e-mail was sent to you in error and the >>>> e-mail >>>> contains patient information, please contact the Partners Compliance >>>> HelpLine at >>>> http://www.partners.org/complianceline . If the e-mail was sent to you >>>> in error >>>> but does not contain patient information, please contact the sender and >>>> properly >>>> dispose of the e-mail. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>>> >>>> >>> >>> >> >> >> -- >> +1 919 869 8849 >> > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 4 16:33:22 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 4 Nov 2013 11:33:22 -0500 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Would probably help with the multiple timezones too... On Mon, Nov 4, 2013 at 11:18 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Creating the event on G+ automatically add it to my calendar :) > > May be we could create a CommonTK Google plus community ? > > > On Mon, Nov 4, 2013 at 11:16 AM, Steve Pieper wrote: > >> I was planning to just start the hangout and then email the link - do you >> find that scheduling the event has advantages? Wouldn't we need a ctk >> google group or something? >> >> Talk to you tomorrow, >> -Steve >> >> >> On Mon, Nov 4, 2013 at 11:12 AM, Jean-Christophe Fillion-Robin < >> jchris.fillionr at kitware.com> wrote: >> >>> Works for me. Could you create a Google event/hangout ? >>> Talk to you tomorrow, >>> Jc >>> >>> >>> On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: >>> >>>> Hi Csaba - >>>> >>>> Andreas is here and working on some of the coding input from Julien >>>> (but the emails to him from the CTK list aren't working right now for some >>>> reason). >>>> >>>> -Steve >>>> >>>> >>>> On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter wrote: >>>> >>>>> Hi Steve, >>>>> >>>>> >>>>> >>>>> Definitely, I can join the hangout tomorrow. Thanks for discussing the >>>>> issue! >>>>> >>>>> >>>>> >>>>> Are the DKFZ fellas going to work on the list-based DICOM browser? >>>>> We'd like to at least start integrating the display database and DICOM >>>>> roles we implemented last time. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>> *Sent:* November 4, 2013 10:02 >>>>> *To:* Csaba Pinter >>>>> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >>>>> >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Hi Csaba, Jc - >>>>> >>>>> >>>>> >>>>> London calling (always wanted to say that). We talked over the issue >>>>> a bit and didn't see any obvious issues but there was a request from some >>>>> folks for a further discussion of the underlying issue so we put it on the >>>>> agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work >>>>> for you two? >>>>> >>>>> >>>>> >>>>> Most of the work here this week so far is on CLI, XNAT/REST API, and >>>>> DICOM. >>>>> >>>>> >>>>> >>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >>>>> >>>>> >>>>> >>>>> -Steve >>>>> >>>>> >>>>> >>>>> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter >>>>> wrote: >>>>> >>>>> Hi JC, >>>>> >>>>> >>>>> >>>>> Yes, it seems to have solved our CTK build problem. The reason I was >>>>> asking about opinions is that I don't know what repercussions it may have >>>>> on other platforms. >>>>> >>>>> If it seems OK the I'd appreciate propagating it to the CTK core or >>>>> ITK. I can create a CTK topic branch containing the change if it makes the >>>>> process easier. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>> jchris.fillionr at kitware.com] >>>>> *Sent:* November 4, 2013 09:30 >>>>> *To:* Csaba Pinter >>>>> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >>>>> >>>>> >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Based on your entry in the CTK tracker. I am assuming it is good to go >>>>> ? >>>>> See https://github.com/commontk/CTK/issues/382 >>>>> >>>>> >>>>> >>>>> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >>>>> jchris.fillionr at kitware.com> wrote: >>>>> >>>>> Hi Csaba, >>>>> >>>>> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >>>>> coordinate with ITK folks so that they also update their FindDCMTK.cmake >>>>> file. >>>>> >>>>> Thanks >>>>> >>>>> Jc >>>>> >>>>> >>>>> [1] >>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>> >>>>> >>>>> >>>>> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter >>>>> wrote: >>>>> >>>>> Hi Steve, >>>>> >>>>> >>>>> >>>>> I was going to do just that, thanks for the reminder! >>>>> >>>>> I created issue https://github.com/commontk/CTK/issues/382. >>>>> >>>>> The main reason I haven't created a topic branch yet is that I would >>>>> like to hear some opinions about it first, as I don't know what >>>>> consequences it has on Linux and Mac. >>>>> >>>>> >>>>> >>>>> FYI my agenda for next week besides this small change is to try our >>>>> display tables and DICOM roles enhancement for the DICOM browser (that >>>>> Andras and I implemented during the last hackfest) against the latest >>>>> listview-based browser and integrate it if it turns out to be working fine. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>> *Sent:* October 31, 2013 16:37 >>>>> >>>>> >>>>> *To:* Csaba Pinter >>>>> *Cc:* CTK mailing list >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Hi Csaba - >>>>> >>>>> >>>>> >>>>> We'll be discussing open issues next week in London - can you make >>>>> sure there's a ctk issue that points to your assembla report? >>>>> >>>>> >>>>> >>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter < >>>>> csaba.pinter at queensu.ca> wrote: >>>>> >>>>> Hi there, >>>>> >>>>> >>>>> >>>>> Any thoughts about the FindDCMTK changes proposed below? >>>>> >>>>> I'd appreciate any feedback. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >>>>> *Sent:* October 10, 2013 15:14 >>>>> *To:* CTK mailing list >>>>> >>>>> >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and >>>>> now I could successfully build CTK with DCMTK. >>>>> >>>>> >>>>> >>>>> As we have the same issue from time to time with CTK in Slicer (but >>>>> finally we could reproduce it, see [1]), I propose adding this flag to >>>>> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >>>>> change is not integrated to DCMTK. >>>>> >>>>> As my CMake knowledge is limited, I don't know if this change causes >>>>> any problem on other operating systems though. >>>>> >>>>> >>>>> >>>>> I'd appreciate to hear your opinions about this. >>>>> >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> [1] >>>>> https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Jean-Christophe Fillion-Robin [ >>>>> mailto:jchris.fillionr at kitware.com ] >>>>> *Sent:* October 4, 2013 18:34 >>>>> *To:* Csaba Pinter >>>>> *Cc:* Andras Lasso; CTK mailing list >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Hi Csaba, >>>>> >>>>> >>>>> >>>>> As illustrated in the enclosed screenshot, build tree can be exported >>>>> into the CMake package registry. As some point, the DCMTK build tree has >>>>> probably been exported [1][2][3]. >>>>> >>>>> Since when building CTK, it is expected that there are no >>>>> DCMTKConfig.cmake available, the first should be failing. In your case, it >>>>> seems not to be failing because it resolves to that previous build added to >>>>> the registery. >>>>> >>>>> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the >>>>> FindDCMTK.cmake module available in CTK. See [4] >>>>> >>>>> >>>>> >>>>> Hth >>>>> >>>>> Jc >>>>> >>>>> >>>>> >>>>> [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >>>>> [2] >>>>> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >>>>> >>>>> [3] >>>>> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >>>>> >>>>> [4] >>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>> >>>>> >>>>> >>>>> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter >>>>> wrote: >>>>> >>>>> Hi Jc, >>>>> >>>>> >>>>> >>>>> I tried building CTK in many ways, but the result is always the same, >>>>> so the problem is completely reproducible, at least on my computer (I >>>>> haven't tried it elsewhere yet, but I plan to). As we have been struggling >>>>> with this issue for quite a while, but haven't been able to consistently >>>>> reproduce it, this is a great opportunity to fix it once and for all. >>>>> >>>>> >>>>> >>>>> I did some digging and this is what I found: >>>>> >>>>> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the >>>>> incorrect directory that is used later (in one of my slicer builds) >>>>> >>>>> - The reason why the DCMTK downloaded by the superbuild is >>>>> not found is most probably that it is a version that doesn't have >>>>> DCMTKConfig.cmake (as you described earlier) >>>>> >>>>> - The same thing (finding the wrong DCMTK) happens if I add >>>>> NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >>>>> >>>>> >>>>> >>>>> Now I don't have any idea how to get the superbuild to use its own >>>>> DCMTK. >>>>> >>>>> Also even if I can do a workaround and have a good build of CTK on my >>>>> machine, this is an issue that other people who want to build CTK on >>>>> Windows while already having a Slicer build have to face. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>> jchris.fillionr at kitware.com] >>>>> *Sent:* October 4, 2013 12:07 >>>>> *To:* Andras Lasso >>>>> *Cc:* Csaba Pinter; CTK mailing list >>>>> >>>>> >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Hi Csaba, Andras, >>>>> >>>>> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >>>>> suggest to add the NO_CMAKE_BUILDS_PATH ? >>>>> >>>>> Let's also note that the FindDCMTK.cmake provided by ITK would have to >>>>> patched also ... >>>>> >>>>> If you can reproduce the problem, with a combination of clearing cache >>>>> + adding some "message()" statement, you should be able to find out or >>>>> confirm what is the source of the problem. >>>>> >>>>> >>>>> >>>>> Jc >>>>> >>>>> >>>>> [1] >>>>> >>>>> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >>>>> >>>>> >>>>> >>>>> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso wrote: >>>>> >>>>> I have this annoying issue during Slicer builds as well: my nightly >>>>> slicer builds usually break after a few days because after I configure >>>>> other projects in CMake CTK finds DCMTK of another project instead of its >>>>> own. >>>>> >>>>> >>>>> >>>>> It may be due to the find_package path finding rule 5: ?Search project >>>>> build trees recently configured in a CMake GUI. This can be skipped if >>>>> NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is >>>>> building multiple dependent projects one after another.? ( >>>>> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK >>>>> should rely on rules 1-4 or disable rule 5 ? or it may be possible that >>>>> something else goes wrong and that?s why the rule 5 kicks in. >>>>> >>>>> >>>>> >>>>> Andras >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >>>>> Fillion-Robin >>>>> *Sent:* Wednesday, October 02, 2013 11:39 AM >>>>> >>>>> >>>>> *To:* Csaba Pinter >>>>> *Cc:* CTK mailing list >>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>> >>>>> >>>>> >>>>> Hi Csaba, >>>>> >>>>> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global >>>>> variable that is empty by default. On the other hand >>>>> "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: >>>>> >>>>> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >>>>> SET(CTK_CMAKE_UTILITIES_DIR >>>>> "/home/jchris/Projects/CTK/Utilities/CMake") >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Otherwise, you will find below the result of my experiment. When >>>>> configured, CTK found the expected DCMTK. >>>>> >>>>> >>>>> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >>>>> "python2.7-dev" doing so the following works. >>>>> >>>>> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build >>>>> system to build VTK or ITK components. Instead, I passed the following >>>>> options: >>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >>>>> -DCTK_ENABLE_DICOM:BOOL=ON >>>>> -DCTK_BUILD_EXAMPLES >>>>> >>>>> >>>>> >>>>> $ git clone git at github.com:commontk/CTK >>>>> >>>>> $ mkdir CTK-Debug >>>>> >>>>> $ cd CTK-Debug >>>>> >>>>> $ cmake >>>>> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >>>>> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >>>>> [...] >>>>> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( >>>>> CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates >>>>> to True >>>>> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 >>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 >>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 >>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 >>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >>>>> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >>>>> -- Generated: >>>>> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >>>>> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >>>>> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] >>>>> required by [ctkCommandLineModuleExplorer] >>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >>>>> required by [ctkCommandLineModuleExplorer] >>>>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >>>>> required by [ctkCommandLineModuleExplorer] >>>>> -- Enabling option >>>>> [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by >>>>> [ctkCommandLineModuleExplorer] >>>>> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >>>>> [ctkCommandLineModuleExplorer] >>>>> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >>>>> [ctkSimplePythonShell] >>>>> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >>>>> [ctkSimplePythonShell] >>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >>>>> version "2.7.4") >>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >>>>> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >>>>> -- Found Git: /usr/bin/git (found version "1.8.1.2") >>>>> -- Configuring done >>>>> -- Generating done >>>>> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >>>>> >>>>> $ make -j6 >>>>> [...] >>>>> [ 90%] Performing configure step for 'CTK-Configure' >>>>> [...] >>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found >>>>> version "2.7.4") >>>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >>>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake >>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake >>>>> -- Looking for include file pthread.h >>>>> -- Looking fothe r include file pthread.h - found >>>>> -- Looking for pthread_create >>>>> -- Looking for pthread_create - not found >>>>> -- Looking for pthread_create in pthreads >>>>> -- Looking for pthread_create in pthreads - not found >>>>> -- Looking for pthread_create in pthread >>>>> -- Looking for pthread_create in pthread - found >>>>> -- Found Threads: TRUE >>>>> -- Found DCMTK: >>>>> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >>>>> >>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >>>>> -- CTKCore: BFD support disabled >>>>> -- Configuring done >>>>> -- Generating done >>>>> [...] >>>>> -- Build files have been written to: >>>>> /home/jchris/Projects/CTK-Debug/CTK-build >>>>> >>>>> [...] >>>>> [100%] Built target CTKWidgetsCppTests >>>>> [100%] Built target CTK-build >>>>> >>>>> >>>>> >>>>> $ cd CTK-build >>>>> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >>>>> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >>>>> >>>>> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this >>>>> is explained by the fact the official DCMTK didn't integrate yet our latest >>>>> and greatest contribution [1] >>>>> >>>>> Hth >>>>> >>>>> Jc >>>>> >>>>> >>>>> [1] >>>>> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> I'm trying to build CTK separately, but I have problems with linking >>>>> DCMTK. >>>>> >>>>> >>>>> >>>>> The way I build CTK: >>>>> >>>>> - Turn on CTK_BUILD_ALL >>>>> >>>>> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge >>>>> and test my changes in the CTK/Core/DICOM project) >>>>> >>>>> - Set the qmake executable >>>>> >>>>> - Configure >>>>> >>>>> - CMake complains about python paths, I set those manually >>>>> >>>>> - Configure, Generate >>>>> >>>>> - Build superbuild >>>>> >>>>> >>>>> >>>>> Then DCMTK is downloaded and built by the superbuild, but later on, >>>>> CTK projects find a completely different DCMTK directory (in my Slicer >>>>> nightly build directory). I tried to manually add the DCMTK directory to >>>>> CMake, but this variable does not exist in the superbuild (it is also not >>>>> passed down), and setting it to the inner CTK project doesn't work. >>>>> >>>>> >>>>> >>>>> Basically no matter what I do, the DCMTK path is set to whatever >>>>> find_project finds. This is what I found in CTKConfig.cmake: >>>>> >>>>> # Update CMake module path so that calling "find_package(DCMTK)" works >>>>> as expected >>>>> >>>>> # after calling "find_package(CTK)" >>>>> >>>>> # Ideally projects like DCMTK or PythonQt should provide both "Config" >>>>> and "Use" files. >>>>> >>>>> set(CMAKE_MODULE_PATH >>>>> >>>>> ${CTK_CMAKE_UTILITIES_DIR} >>>>> >>>>> ${CMAKE_MODULE_PATH} >>>>> >>>>> ) >>>>> >>>>> >>>>> >>>>> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so >>>>> there is no chance DCMTK is found correctly. >>>>> >>>>> >>>>> >>>>> Can someone please help with this? >>>>> >>>>> >>>>> >>>>> Thanks a lot, >>>>> >>>>> csaba >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> Csaba Pinter >>>>> >>>>> Medical Software Systems Engineer >>>>> >>>>> Laboratory for Percutanous Surgery >>>>> >>>>> School of Computing >>>>> >>>>> Queen?s University >>>>> >>>>> Kingston, ON, Canada >>>>> >>>>> Email: csaba.pinter at queensu.ca >>>>> >>>>> Web: http://perk.cs.queensu.ca >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> +1 919 869 8849 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> +1 919 869 8849 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> +1 919 869 8849 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> >>>>> The information in this e-mail is intended only for the person to whom >>>>> it is >>>>> addressed. If you believe this e-mail was sent to you in error and the >>>>> e-mail >>>>> contains patient information, please contact the Partners Compliance >>>>> HelpLine at >>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>> you in error >>>>> but does not contain patient information, please contact the sender >>>>> and properly >>>>> dispose of the e-mail. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> +1 919 869 8849 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> +1 919 869 8849 >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >> >> > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Nov 4 17:00:39 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 4 Nov 2013 12:00:39 -0500 Subject: [Ctk-developers] CTK Google Plus community (was: Re: DCMTK_DIR is found incorrectly) Message-ID: I propose to name the community "CTK BarCamp". See http://en.wikipedia.org/wiki/BarCamp What do you think ? On Mon, Nov 4, 2013 at 11:33 AM, Steve Pieper wrote: > Would probably help with the multiple timezones too... > > > On Mon, Nov 4, 2013 at 11:18 AM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> Creating the event on G+ automatically add it to my calendar :) >> >> May be we could create a CommonTK Google plus community ? >> >> >> On Mon, Nov 4, 2013 at 11:16 AM, Steve Pieper wrote: >> >>> I was planning to just start the hangout and then email the link - do >>> you find that scheduling the event has advantages? Wouldn't we need a ctk >>> google group or something? >>> >>> Talk to you tomorrow, >>> -Steve >>> >>> >>> On Mon, Nov 4, 2013 at 11:12 AM, Jean-Christophe Fillion-Robin < >>> jchris.fillionr at kitware.com> wrote: >>> >>>> Works for me. Could you create a Google event/hangout ? >>>> Talk to you tomorrow, >>>> Jc >>>> >>>> >>>> On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: >>>> >>>>> Hi Csaba - >>>>> >>>>> Andreas is here and working on some of the coding input from Julien >>>>> (but the emails to him from the CTK list aren't working right now for some >>>>> reason). >>>>> >>>>> -Steve >>>>> >>>>> >>>>> On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter >>>> > wrote: >>>>> >>>>>> Hi Steve, >>>>>> >>>>>> >>>>>> >>>>>> Definitely, I can join the hangout tomorrow. Thanks for discussing >>>>>> the issue! >>>>>> >>>>>> >>>>>> >>>>>> Are the DKFZ fellas going to work on the list-based DICOM browser? >>>>>> We'd like to at least start integrating the display database and DICOM >>>>>> roles we implemented last time. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>>> *Sent:* November 4, 2013 10:02 >>>>>> *To:* Csaba Pinter >>>>>> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >>>>>> >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Hi Csaba, Jc - >>>>>> >>>>>> >>>>>> >>>>>> London calling (always wanted to say that). We talked over the issue >>>>>> a bit and didn't see any obvious issues but there was a request from some >>>>>> folks for a further discussion of the underlying issue so we put it on the >>>>>> agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work >>>>>> for you two? >>>>>> >>>>>> >>>>>> >>>>>> Most of the work here this week so far is on CLI, XNAT/REST API, and >>>>>> DICOM. >>>>>> >>>>>> >>>>>> >>>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >>>>>> >>>>>> >>>>>> >>>>>> -Steve >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter >>>>>> wrote: >>>>>> >>>>>> Hi JC, >>>>>> >>>>>> >>>>>> >>>>>> Yes, it seems to have solved our CTK build problem. The reason I was >>>>>> asking about opinions is that I don't know what repercussions it may have >>>>>> on other platforms. >>>>>> >>>>>> If it seems OK the I'd appreciate propagating it to the CTK core or >>>>>> ITK. I can create a CTK topic branch containing the change if it makes the >>>>>> process easier. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>>> jchris.fillionr at kitware.com] >>>>>> *Sent:* November 4, 2013 09:30 >>>>>> *To:* Csaba Pinter >>>>>> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >>>>>> >>>>>> >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Based on your entry in the CTK tracker. I am assuming it is good to >>>>>> go ? >>>>>> See https://github.com/commontk/CTK/issues/382 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >>>>>> jchris.fillionr at kitware.com> wrote: >>>>>> >>>>>> Hi Csaba, >>>>>> >>>>>> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >>>>>> coordinate with ITK folks so that they also update their FindDCMTK.cmake >>>>>> file. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jc >>>>>> >>>>>> >>>>>> [1] >>>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter < >>>>>> csaba.pinter at queensu.ca> wrote: >>>>>> >>>>>> Hi Steve, >>>>>> >>>>>> >>>>>> >>>>>> I was going to do just that, thanks for the reminder! >>>>>> >>>>>> I created issue https://github.com/commontk/CTK/issues/382. >>>>>> >>>>>> The main reason I haven't created a topic branch yet is that I would >>>>>> like to hear some opinions about it first, as I don't know what >>>>>> consequences it has on Linux and Mac. >>>>>> >>>>>> >>>>>> >>>>>> FYI my agenda for next week besides this small change is to try our >>>>>> display tables and DICOM roles enhancement for the DICOM browser (that >>>>>> Andras and I implemented during the last hackfest) against the latest >>>>>> listview-based browser and integrate it if it turns out to be working fine. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>>> *Sent:* October 31, 2013 16:37 >>>>>> >>>>>> >>>>>> *To:* Csaba Pinter >>>>>> *Cc:* CTK mailing list >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Hi Csaba - >>>>>> >>>>>> >>>>>> >>>>>> We'll be discussing open issues next week in London - can you make >>>>>> sure there's a ctk issue that points to your assembla report? >>>>>> >>>>>> >>>>>> >>>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter < >>>>>> csaba.pinter at queensu.ca> wrote: >>>>>> >>>>>> Hi there, >>>>>> >>>>>> >>>>>> >>>>>> Any thoughts about the FindDCMTK changes proposed below? >>>>>> >>>>>> I'd appreciate any feedback. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >>>>>> *Sent:* October 10, 2013 15:14 >>>>>> *To:* CTK mailing list >>>>>> >>>>>> >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and >>>>>> now I could successfully build CTK with DCMTK. >>>>>> >>>>>> >>>>>> >>>>>> As we have the same issue from time to time with CTK in Slicer (but >>>>>> finally we could reproduce it, see [1]), I propose adding this flag to >>>>>> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >>>>>> change is not integrated to DCMTK. >>>>>> >>>>>> As my CMake knowledge is limited, I don't know if this change causes >>>>>> any problem on other operating systems though. >>>>>> >>>>>> >>>>>> >>>>>> I'd appreciate to hear your opinions about this. >>>>>> >>>>>> >>>>>> >>>>>> Thank you, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> [1] >>>>>> https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Jean-Christophe Fillion-Robin [ >>>>>> mailto:jchris.fillionr at kitware.com ] >>>>>> *Sent:* October 4, 2013 18:34 >>>>>> *To:* Csaba Pinter >>>>>> *Cc:* Andras Lasso; CTK mailing list >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Hi Csaba, >>>>>> >>>>>> >>>>>> >>>>>> As illustrated in the enclosed screenshot, build tree can be exported >>>>>> into the CMake package registry. As some point, the DCMTK build tree has >>>>>> probably been exported [1][2][3]. >>>>>> >>>>>> Since when building CTK, it is expected that there are no >>>>>> DCMTKConfig.cmake available, the first should be failing. In your case, it >>>>>> seems not to be failing because it resolves to that previous build added to >>>>>> the registery. >>>>>> >>>>>> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the >>>>>> FindDCMTK.cmake module available in CTK. See [4] >>>>>> >>>>>> >>>>>> >>>>>> Hth >>>>>> >>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>>> [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >>>>>> [2] >>>>>> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >>>>>> >>>>>> [3] >>>>>> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >>>>>> >>>>>> [4] >>>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter >>>>>> wrote: >>>>>> >>>>>> Hi Jc, >>>>>> >>>>>> >>>>>> >>>>>> I tried building CTK in many ways, but the result is always the same, >>>>>> so the problem is completely reproducible, at least on my computer (I >>>>>> haven't tried it elsewhere yet, but I plan to). As we have been struggling >>>>>> with this issue for quite a while, but haven't been able to consistently >>>>>> reproduce it, this is a great opportunity to fix it once and for all. >>>>>> >>>>>> >>>>>> >>>>>> I did some digging and this is what I found: >>>>>> >>>>>> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the >>>>>> incorrect directory that is used later (in one of my slicer builds) >>>>>> >>>>>> - The reason why the DCMTK downloaded by the superbuild is >>>>>> not found is most probably that it is a version that doesn't have >>>>>> DCMTKConfig.cmake (as you described earlier) >>>>>> >>>>>> - The same thing (finding the wrong DCMTK) happens if I add >>>>>> NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >>>>>> >>>>>> >>>>>> >>>>>> Now I don't have any idea how to get the superbuild to use its own >>>>>> DCMTK. >>>>>> >>>>>> Also even if I can do a workaround and have a good build of CTK on my >>>>>> machine, this is an issue that other people who want to build CTK on >>>>>> Windows while already having a Slicer build have to face. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>>> jchris.fillionr at kitware.com] >>>>>> *Sent:* October 4, 2013 12:07 >>>>>> *To:* Andras Lasso >>>>>> *Cc:* Csaba Pinter; CTK mailing list >>>>>> >>>>>> >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Hi Csaba, Andras, >>>>>> >>>>>> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >>>>>> suggest to add the NO_CMAKE_BUILDS_PATH ? >>>>>> >>>>>> Let's also note that the FindDCMTK.cmake provided by ITK would have >>>>>> to patched also ... >>>>>> >>>>>> If you can reproduce the problem, with a combination of clearing >>>>>> cache + adding some "message()" statement, you should be able to find out >>>>>> or confirm what is the source of the problem. >>>>>> >>>>>> >>>>>> >>>>>> Jc >>>>>> >>>>>> >>>>>> [1] >>>>>> >>>>>> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso >>>>>> wrote: >>>>>> >>>>>> I have this annoying issue during Slicer builds as well: my nightly >>>>>> slicer builds usually break after a few days because after I configure >>>>>> other projects in CMake CTK finds DCMTK of another project instead of its >>>>>> own. >>>>>> >>>>>> >>>>>> >>>>>> It may be due to the find_package path finding rule 5: ?Search >>>>>> project build trees recently configured in a CMake GUI. This can be skipped >>>>>> if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user >>>>>> is building multiple dependent projects one after another.? ( >>>>>> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK >>>>>> should rely on rules 1-4 or disable rule 5 ? or it may be possible that >>>>>> something else goes wrong and that?s why the rule 5 kicks in. >>>>>> >>>>>> >>>>>> >>>>>> Andras >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >>>>>> Fillion-Robin >>>>>> *Sent:* Wednesday, October 02, 2013 11:39 AM >>>>>> >>>>>> >>>>>> *To:* Csaba Pinter >>>>>> *Cc:* CTK mailing list >>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>> >>>>>> >>>>>> >>>>>> Hi Csaba, >>>>>> >>>>>> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global >>>>>> variable that is empty by default. On the other hand >>>>>> "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: >>>>>> >>>>>> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >>>>>> SET(CTK_CMAKE_UTILITIES_DIR >>>>>> "/home/jchris/Projects/CTK/Utilities/CMake") >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Otherwise, you will find below the result of my experiment. When >>>>>> configured, CTK found the expected DCMTK. >>>>>> >>>>>> >>>>>> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >>>>>> "python2.7-dev" doing so the following works. >>>>>> >>>>>> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build >>>>>> system to build VTK or ITK components. Instead, I passed the following >>>>>> options: >>>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >>>>>> -DCTK_ENABLE_DICOM:BOOL=ON >>>>>> -DCTK_BUILD_EXAMPLES >>>>>> >>>>>> >>>>>> >>>>>> $ git clone git at github.com:commontk/CTK >>>>>> >>>>>> $ mkdir CTK-Debug >>>>>> >>>>>> $ cd CTK-Debug >>>>>> >>>>>> $ cmake >>>>>> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >>>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >>>>>> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >>>>>> [...] >>>>>> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( >>>>>> CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates >>>>>> to True >>>>>> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 >>>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 >>>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 >>>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ >>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >>>>>> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >>>>>> -- Generated: >>>>>> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >>>>>> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >>>>>> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] >>>>>> required by [ctkCommandLineModuleExplorer] >>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >>>>>> required by [ctkCommandLineModuleExplorer] >>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >>>>>> required by [ctkCommandLineModuleExplorer] >>>>>> -- Enabling option >>>>>> [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by >>>>>> [ctkCommandLineModuleExplorer] >>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >>>>>> [ctkCommandLineModuleExplorer] >>>>>> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >>>>>> [ctkSimplePythonShell] >>>>>> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >>>>>> [ctkSimplePythonShell] >>>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so(found version "2.7.4") >>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >>>>>> -- Found Git: /usr/bin/git (found version "1.8.1.2") >>>>>> -- Configuring done >>>>>> -- Generating done >>>>>> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >>>>>> >>>>>> $ make -j6 >>>>>> [...] >>>>>> [ 90%] Performing configure step for 'CTK-Configure' >>>>>> [...] >>>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so(found version "2.7.4") >>>>>> -- Generated: >>>>>> /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >>>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake >>>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >>>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake >>>>>> -- Looking for include file pthread.h >>>>>> -- Looking fothe r include file pthread.h - found >>>>>> -- Looking for pthread_create >>>>>> -- Looking for pthread_create - not found >>>>>> -- Looking for pthread_create in pthreads >>>>>> -- Looking for pthread_create in pthreads - not found >>>>>> -- Looking for pthread_create in pthread >>>>>> -- Looking for pthread_create in pthread - found >>>>>> -- Found Threads: TRUE >>>>>> -- Found DCMTK: >>>>>> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >>>>>> >>>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >>>>>> -- CTKCore: BFD support disabled >>>>>> -- Configuring done >>>>>> -- Generating done >>>>>> [...] >>>>>> -- Build files have been written to: >>>>>> /home/jchris/Projects/CTK-Debug/CTK-build >>>>>> >>>>>> [...] >>>>>> [100%] Built target CTKWidgetsCppTests >>>>>> [100%] Built target CTK-build >>>>>> >>>>>> >>>>>> >>>>>> $ cd CTK-build >>>>>> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >>>>>> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >>>>>> >>>>>> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this >>>>>> is explained by the fact the official DCMTK didn't integrate yet our latest >>>>>> and greatest contribution [1] >>>>>> >>>>>> Hth >>>>>> >>>>>> Jc >>>>>> >>>>>> >>>>>> [1] >>>>>> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter < >>>>>> csaba.pinter at queensu.ca> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> I'm trying to build CTK separately, but I have problems with linking >>>>>> DCMTK. >>>>>> >>>>>> >>>>>> >>>>>> The way I build CTK: >>>>>> >>>>>> - Turn on CTK_BUILD_ALL >>>>>> >>>>>> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge >>>>>> and test my changes in the CTK/Core/DICOM project) >>>>>> >>>>>> - Set the qmake executable >>>>>> >>>>>> - Configure >>>>>> >>>>>> - CMake complains about python paths, I set those manually >>>>>> >>>>>> - Configure, Generate >>>>>> >>>>>> - Build superbuild >>>>>> >>>>>> >>>>>> >>>>>> Then DCMTK is downloaded and built by the superbuild, but later on, >>>>>> CTK projects find a completely different DCMTK directory (in my Slicer >>>>>> nightly build directory). I tried to manually add the DCMTK directory to >>>>>> CMake, but this variable does not exist in the superbuild (it is also not >>>>>> passed down), and setting it to the inner CTK project doesn't work. >>>>>> >>>>>> >>>>>> >>>>>> Basically no matter what I do, the DCMTK path is set to whatever >>>>>> find_project finds. This is what I found in CTKConfig.cmake: >>>>>> >>>>>> # Update CMake module path so that calling "find_package(DCMTK)" >>>>>> works as expected >>>>>> >>>>>> # after calling "find_package(CTK)" >>>>>> >>>>>> # Ideally projects like DCMTK or PythonQt should provide both >>>>>> "Config" and "Use" files. >>>>>> >>>>>> set(CMAKE_MODULE_PATH >>>>>> >>>>>> ${CTK_CMAKE_UTILITIES_DIR} >>>>>> >>>>>> ${CMAKE_MODULE_PATH} >>>>>> >>>>>> ) >>>>>> >>>>>> >>>>>> >>>>>> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so >>>>>> there is no chance DCMTK is found correctly. >>>>>> >>>>>> >>>>>> >>>>>> Can someone please help with this? >>>>>> >>>>>> >>>>>> >>>>>> Thanks a lot, >>>>>> >>>>>> csaba >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Csaba Pinter >>>>>> >>>>>> Medical Software Systems Engineer >>>>>> >>>>>> Laboratory for Percutanous Surgery >>>>>> >>>>>> School of Computing >>>>>> >>>>>> Queen?s University >>>>>> >>>>>> Kingston, ON, Canada >>>>>> >>>>>> Email: csaba.pinter at queensu.ca >>>>>> >>>>>> Web: http://perk.cs.queensu.ca >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +1 919 869 8849 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +1 919 869 8849 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +1 919 869 8849 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>> >>>>>> >>>>>> The information in this e-mail is intended only for the person to >>>>>> whom it is >>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>> the e-mail >>>>>> contains patient information, please contact the Partners Compliance >>>>>> HelpLine at >>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>> you in error >>>>>> but does not contain patient information, please contact the sender >>>>>> and properly >>>>>> dispose of the e-mail. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +1 919 869 8849 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +1 919 869 8849 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>> >>> >> >> >> -- >> +1 919 869 8849 >> > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 4 18:08:09 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 4 Nov 2013 13:08:09 -0500 Subject: [Ctk-developers] CTK Google Plus community (was: Re: DCMTK_DIR is found incorrectly) In-Reply-To: References: Message-ID: Sounds like a consistent naming convention :) On Mon, Nov 4, 2013 at 12:00 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > I propose to name the community "CTK BarCamp". See > http://en.wikipedia.org/wiki/BarCamp > > What do you think ? > > > On Mon, Nov 4, 2013 at 11:33 AM, Steve Pieper wrote: > >> Would probably help with the multiple timezones too... >> >> >> On Mon, Nov 4, 2013 at 11:18 AM, Jean-Christophe Fillion-Robin < >> jchris.fillionr at kitware.com> wrote: >> >>> Creating the event on G+ automatically add it to my calendar :) >>> >>> May be we could create a CommonTK Google plus community ? >>> >>> >>> On Mon, Nov 4, 2013 at 11:16 AM, Steve Pieper wrote: >>> >>>> I was planning to just start the hangout and then email the link - do >>>> you find that scheduling the event has advantages? Wouldn't we need a ctk >>>> google group or something? >>>> >>>> Talk to you tomorrow, >>>> -Steve >>>> >>>> >>>> On Mon, Nov 4, 2013 at 11:12 AM, Jean-Christophe Fillion-Robin < >>>> jchris.fillionr at kitware.com> wrote: >>>> >>>>> Works for me. Could you create a Google event/hangout ? >>>>> Talk to you tomorrow, >>>>> Jc >>>>> >>>>> >>>>> On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: >>>>> >>>>>> Hi Csaba - >>>>>> >>>>>> Andreas is here and working on some of the coding input from Julien >>>>>> (but the emails to him from the CTK list aren't working right now for some >>>>>> reason). >>>>>> >>>>>> -Steve >>>>>> >>>>>> >>>>>> On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter < >>>>>> csaba.pinter at queensu.ca> wrote: >>>>>> >>>>>>> Hi Steve, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Definitely, I can join the hangout tomorrow. Thanks for discussing >>>>>>> the issue! >>>>>>> >>>>>>> >>>>>>> >>>>>>> Are the DKFZ fellas going to work on the list-based DICOM browser? >>>>>>> We'd like to at least start integrating the display database and DICOM >>>>>>> roles we implemented last time. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>>>> *Sent:* November 4, 2013 10:02 >>>>>>> *To:* Csaba Pinter >>>>>>> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >>>>>>> >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Csaba, Jc - >>>>>>> >>>>>>> >>>>>>> >>>>>>> London calling (always wanted to say that). We talked over the >>>>>>> issue a bit and didn't see any obvious issues but there was a request from >>>>>>> some folks for a further discussion of the underlying issue so we put it on >>>>>>> the agenda for a Tuesday afternoon (15:00 London time) hangout. Does that >>>>>>> work for you two? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Most of the work here this week so far is on CLI, XNAT/REST API, and >>>>>>> DICOM. >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter < >>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>> >>>>>>> Hi JC, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, it seems to have solved our CTK build problem. The reason I was >>>>>>> asking about opinions is that I don't know what repercussions it may have >>>>>>> on other platforms. >>>>>>> >>>>>>> If it seems OK the I'd appreciate propagating it to the CTK core or >>>>>>> ITK. I can create a CTK topic branch containing the change if it makes the >>>>>>> process easier. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>>>> jchris.fillionr at kitware.com] >>>>>>> *Sent:* November 4, 2013 09:30 >>>>>>> *To:* Csaba Pinter >>>>>>> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >>>>>>> >>>>>>> >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Based on your entry in the CTK tracker. I am assuming it is good to >>>>>>> go ? >>>>>>> See https://github.com/commontk/CTK/issues/382 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >>>>>>> jchris.fillionr at kitware.com> wrote: >>>>>>> >>>>>>> Hi Csaba, >>>>>>> >>>>>>> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >>>>>>> coordinate with ITK folks so that they also update their FindDCMTK.cmake >>>>>>> file. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter < >>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>> >>>>>>> Hi Steve, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I was going to do just that, thanks for the reminder! >>>>>>> >>>>>>> I created issue https://github.com/commontk/CTK/issues/382. >>>>>>> >>>>>>> The main reason I haven't created a topic branch yet is that I would >>>>>>> like to hear some opinions about it first, as I don't know what >>>>>>> consequences it has on Linux and Mac. >>>>>>> >>>>>>> >>>>>>> >>>>>>> FYI my agenda for next week besides this small change is to try our >>>>>>> display tables and DICOM roles enhancement for the DICOM browser (that >>>>>>> Andras and I implemented during the last hackfest) against the latest >>>>>>> listview-based browser and integrate it if it turns out to be working fine. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>>>> *Sent:* October 31, 2013 16:37 >>>>>>> >>>>>>> >>>>>>> *To:* Csaba Pinter >>>>>>> *Cc:* CTK mailing list >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Csaba - >>>>>>> >>>>>>> >>>>>>> >>>>>>> We'll be discussing open issues next week in London - can you make >>>>>>> sure there's a ctk issue that points to your assembla report? >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter < >>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any thoughts about the FindDCMTK changes proposed below? >>>>>>> >>>>>>> I'd appreciate any feedback. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >>>>>>> *Sent:* October 10, 2013 15:14 >>>>>>> *To:* CTK mailing list >>>>>>> >>>>>>> >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and >>>>>>> now I could successfully build CTK with DCMTK. >>>>>>> >>>>>>> >>>>>>> >>>>>>> As we have the same issue from time to time with CTK in Slicer (but >>>>>>> finally we could reproduce it, see [1]), I propose adding this flag to >>>>>>> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >>>>>>> change is not integrated to DCMTK. >>>>>>> >>>>>>> As my CMake knowledge is limited, I don't know if this change causes >>>>>>> any problem on other operating systems though. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'd appreciate to hear your opinions about this. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Jean-Christophe Fillion-Robin [ >>>>>>> mailto:jchris.fillionr at kitware.com ] >>>>>>> *Sent:* October 4, 2013 18:34 >>>>>>> *To:* Csaba Pinter >>>>>>> *Cc:* Andras Lasso; CTK mailing list >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Csaba, >>>>>>> >>>>>>> >>>>>>> >>>>>>> As illustrated in the enclosed screenshot, build tree can be >>>>>>> exported into the CMake package registry. As some point, the DCMTK build >>>>>>> tree has probably been exported [1][2][3]. >>>>>>> >>>>>>> Since when building CTK, it is expected that there are no >>>>>>> DCMTKConfig.cmake available, the first should be failing. In your case, it >>>>>>> seems not to be failing because it resolves to that previous build added to >>>>>>> the registery. >>>>>>> >>>>>>> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to >>>>>>> the FindDCMTK.cmake module available in CTK. See [4] >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hth >>>>>>> >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >>>>>>> [2] >>>>>>> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >>>>>>> >>>>>>> [3] >>>>>>> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >>>>>>> >>>>>>> [4] >>>>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter < >>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>> >>>>>>> Hi Jc, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I tried building CTK in many ways, but the result is always the >>>>>>> same, so the problem is completely reproducible, at least on my computer (I >>>>>>> haven't tried it elsewhere yet, but I plan to). As we have been struggling >>>>>>> with this issue for quite a while, but haven't been able to consistently >>>>>>> reproduce it, this is a great opportunity to fix it once and for all. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I did some digging and this is what I found: >>>>>>> >>>>>>> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in >>>>>>> the incorrect directory that is used later (in one of my slicer builds) >>>>>>> >>>>>>> - The reason why the DCMTK downloaded by the superbuild is >>>>>>> not found is most probably that it is a version that doesn't have >>>>>>> DCMTKConfig.cmake (as you described earlier) >>>>>>> >>>>>>> - The same thing (finding the wrong DCMTK) happens if I >>>>>>> add NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >>>>>>> >>>>>>> >>>>>>> >>>>>>> Now I don't have any idea how to get the superbuild to use its own >>>>>>> DCMTK. >>>>>>> >>>>>>> Also even if I can do a workaround and have a good build of CTK on >>>>>>> my machine, this is an issue that other people who want to build CTK on >>>>>>> Windows while already having a Slicer build have to face. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>>>> jchris.fillionr at kitware.com] >>>>>>> *Sent:* October 4, 2013 12:07 >>>>>>> *To:* Andras Lasso >>>>>>> *Cc:* Csaba Pinter; CTK mailing list >>>>>>> >>>>>>> >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Csaba, Andras, >>>>>>> >>>>>>> Within the file FindDCMTK.cmake [1] provided by CTK, where would you >>>>>>> suggest to add the NO_CMAKE_BUILDS_PATH ? >>>>>>> >>>>>>> Let's also note that the FindDCMTK.cmake provided by ITK would have >>>>>>> to patched also ... >>>>>>> >>>>>>> If you can reproduce the problem, with a combination of clearing >>>>>>> cache + adding some "message()" statement, you should be able to find out >>>>>>> or confirm what is the source of the problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso >>>>>>> wrote: >>>>>>> >>>>>>> I have this annoying issue during Slicer builds as well: my nightly >>>>>>> slicer builds usually break after a few days because after I configure >>>>>>> other projects in CMake CTK finds DCMTK of another project instead of its >>>>>>> own. >>>>>>> >>>>>>> >>>>>>> >>>>>>> It may be due to the find_package path finding rule 5: ?Search >>>>>>> project build trees recently configured in a CMake GUI. This can be skipped >>>>>>> if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user >>>>>>> is building multiple dependent projects one after another.? ( >>>>>>> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK >>>>>>> should rely on rules 1-4 or disable rule 5 ? or it may be possible that >>>>>>> something else goes wrong and that?s why the rule 5 kicks in. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Andras >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >>>>>>> Fillion-Robin >>>>>>> *Sent:* Wednesday, October 02, 2013 11:39 AM >>>>>>> >>>>>>> >>>>>>> *To:* Csaba Pinter >>>>>>> *Cc:* CTK mailing list >>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Csaba, >>>>>>> >>>>>>> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global >>>>>>> variable that is empty by default. On the other hand >>>>>>> "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: >>>>>>> >>>>>>> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >>>>>>> SET(CTK_CMAKE_UTILITIES_DIR >>>>>>> "/home/jchris/Projects/CTK/Utilities/CMake") >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Otherwise, you will find below the result of my experiment. When >>>>>>> configured, CTK found the expected DCMTK. >>>>>>> >>>>>>> >>>>>>> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >>>>>>> "python2.7-dev" doing so the following works. >>>>>>> >>>>>>> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build >>>>>>> system to build VTK or ITK components. Instead, I passed the following >>>>>>> options: >>>>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >>>>>>> -DCTK_ENABLE_DICOM:BOOL=ON >>>>>>> -DCTK_BUILD_EXAMPLES >>>>>>> >>>>>>> >>>>>>> >>>>>>> $ git clone git at github.com:commontk/CTK >>>>>>> >>>>>>> $ mkdir CTK-Debug >>>>>>> >>>>>>> $ cd CTK-Debug >>>>>>> >>>>>>> $ cmake >>>>>>> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >>>>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >>>>>>> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >>>>>>> [...] >>>>>>> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR >>>>>>> ( CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] >>>>>>> evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >>>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >>>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ >>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ >>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 >>>>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ >>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >>>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >>>>>>> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >>>>>>> -- Generated: >>>>>>> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >>>>>>> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >>>>>>> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] >>>>>>> required by [ctkCommandLineModuleExplorer] >>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >>>>>>> required by [ctkCommandLineModuleExplorer] >>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] >>>>>>> required by [ctkCommandLineModuleExplorer] >>>>>>> -- Enabling option >>>>>>> [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by >>>>>>> [ctkCommandLineModuleExplorer] >>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >>>>>>> [ctkCommandLineModuleExplorer] >>>>>>> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >>>>>>> [ctkSimplePythonShell] >>>>>>> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >>>>>>> [ctkSimplePythonShell] >>>>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so(found version "2.7.4") >>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >>>>>>> -- Found Git: /usr/bin/git (found version "1.8.1.2") >>>>>>> -- Configuring done >>>>>>> -- Generating done >>>>>>> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >>>>>>> >>>>>>> $ make -j6 >>>>>>> [...] >>>>>>> [ 90%] Performing configure step for 'CTK-Configure' >>>>>>> [...] >>>>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so(found version "2.7.4") >>>>>>> -- Generated: >>>>>>> /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >>>>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake >>>>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >>>>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake >>>>>>> -- Looking for include file pthread.h >>>>>>> -- Looking fothe r include file pthread.h - found >>>>>>> -- Looking for pthread_create >>>>>>> -- Looking for pthread_create - not found >>>>>>> -- Looking for pthread_create in pthreads >>>>>>> -- Looking for pthread_create in pthreads - not found >>>>>>> -- Looking for pthread_create in pthread >>>>>>> -- Looking for pthread_create in pthread - found >>>>>>> -- Found Threads: TRUE >>>>>>> -- Found DCMTK: >>>>>>> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >>>>>>> >>>>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >>>>>>> -- CTKCore: BFD support disabled >>>>>>> -- Configuring done >>>>>>> -- Generating done >>>>>>> [...] >>>>>>> -- Build files have been written to: >>>>>>> /home/jchris/Projects/CTK-Debug/CTK-build >>>>>>> >>>>>>> [...] >>>>>>> [100%] Built target CTKWidgetsCppTests >>>>>>> [100%] Built target CTK-build >>>>>>> >>>>>>> >>>>>>> >>>>>>> $ cd CTK-build >>>>>>> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >>>>>>> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >>>>>>> >>>>>>> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, >>>>>>> this is explained by the fact the official DCMTK didn't integrate yet our >>>>>>> latest and greatest contribution [1] >>>>>>> >>>>>>> Hth >>>>>>> >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter < >>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm trying to build CTK separately, but I have problems with linking >>>>>>> DCMTK. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The way I build CTK: >>>>>>> >>>>>>> - Turn on CTK_BUILD_ALL >>>>>>> >>>>>>> - Turn on CTK_ENABLE_DICOM (I need this as I want to merge >>>>>>> and test my changes in the CTK/Core/DICOM project) >>>>>>> >>>>>>> - Set the qmake executable >>>>>>> >>>>>>> - Configure >>>>>>> >>>>>>> - CMake complains about python paths, I set those manually >>>>>>> >>>>>>> - Configure, Generate >>>>>>> >>>>>>> - Build superbuild >>>>>>> >>>>>>> >>>>>>> >>>>>>> Then DCMTK is downloaded and built by the superbuild, but later on, >>>>>>> CTK projects find a completely different DCMTK directory (in my Slicer >>>>>>> nightly build directory). I tried to manually add the DCMTK directory to >>>>>>> CMake, but this variable does not exist in the superbuild (it is also not >>>>>>> passed down), and setting it to the inner CTK project doesn't work. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Basically no matter what I do, the DCMTK path is set to whatever >>>>>>> find_project finds. This is what I found in CTKConfig.cmake: >>>>>>> >>>>>>> # Update CMake module path so that calling "find_package(DCMTK)" >>>>>>> works as expected >>>>>>> >>>>>>> # after calling "find_package(CTK)" >>>>>>> >>>>>>> # Ideally projects like DCMTK or PythonQt should provide both >>>>>>> "Config" and "Use" files. >>>>>>> >>>>>>> set(CMAKE_MODULE_PATH >>>>>>> >>>>>>> ${CTK_CMAKE_UTILITIES_DIR} >>>>>>> >>>>>>> ${CMAKE_MODULE_PATH} >>>>>>> >>>>>>> ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so >>>>>>> there is no chance DCMTK is found correctly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can someone please help with this? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks a lot, >>>>>>> >>>>>>> csaba >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> Csaba Pinter >>>>>>> >>>>>>> Medical Software Systems Engineer >>>>>>> >>>>>>> Laboratory for Percutanous Surgery >>>>>>> >>>>>>> School of Computing >>>>>>> >>>>>>> Queen?s University >>>>>>> >>>>>>> Kingston, ON, Canada >>>>>>> >>>>>>> Email: csaba.pinter at queensu.ca >>>>>>> >>>>>>> Web: http://perk.cs.queensu.ca >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ctk-developers mailing list >>>>>>> Ctk-developers at commontk.org >>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +1 919 869 8849 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +1 919 869 8849 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +1 919 869 8849 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ctk-developers mailing list >>>>>>> Ctk-developers at commontk.org >>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>> >>>>>>> >>>>>>> The information in this e-mail is intended only for the person to >>>>>>> whom it is >>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>> the e-mail >>>>>>> contains patient information, please contact the Partners Compliance >>>>>>> HelpLine at >>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>>> you in error >>>>>>> but does not contain patient information, please contact the sender >>>>>>> and properly >>>>>>> dispose of the e-mail. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ctk-developers mailing list >>>>>>> Ctk-developers at commontk.org >>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +1 919 869 8849 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +1 919 869 8849 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> +1 919 869 8849 >>>>> >>>> >>>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >> >> > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 4 18:11:11 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 4 Nov 2013 13:11:11 -0500 Subject: [Ctk-developers] hangout tomorrow 10am US Eastern / 15:00 London time Message-ID: In case people didn't see the note in the previous emails, we're planning to set up a google hangout tomorrow to link people into the London hackfest to go over some of the ongoing projects. Please join if your interested. Instructions to join the hangout will be forthcoming. Cheers, -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.fetzer at Dkfz-Heidelberg.de Tue Nov 5 11:36:54 2013 From: a.fetzer at Dkfz-Heidelberg.de (Fetzer, Andreas) Date: Tue, 5 Nov 2013 12:36:54 +0100 Subject: [Ctk-developers] DCMTK_DIR is found incorrectly In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555D1732@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D3EE2@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555D8850@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555DB9C1@MP-DUP-MBX-01.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EB1CA@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC141@MP-DUP-MBX-02.AD.QUEENSU.CA> <04C6BCB5F77FFF449DAE728C597984555EC183@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: <36214065-6097-42C0-B270-9550003D19CE@dkfz-heidelberg.de> Hi, I think the email should work now again. There was indeed a problem at our institute. As Steve wrote I am working on the input from Julien. I also stumbled over two minor issues in the new dicim widgets which I want to fix today. If you have any question or remarks regarding the new widgets just send me an email. Andreas On Nov 4, 2013, at 4:04 PM, Steve Pieper > wrote: Hi Csaba - Andreas is here and working on some of the coding input from Julien (but the emails to him from the CTK list aren't working right now for some reason). -Steve On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter > wrote: Hi Steve, Definitely, I can join the hangout tomorrow. Thanks for discussing the issue! Are the DKFZ fellas going to work on the list-based DICOM browser? We'd like to at least start integrating the display database and DICOM roles we implemented last time. Thanks, csaba From: Steve Pieper [mailto:pieper at ibility.net] Sent: November 4, 2013 10:02 To: Csaba Pinter Cc: Jean-Christophe Fillion-Robin; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, Jc - London calling (always wanted to say that). We talked over the issue a bit and didn't see any obvious issues but there was a request from some folks for a further discussion of the underlying issue so we put it on the agenda for a Tuesday afternoon (15:00 London time) hangout. Does that work for you two? Most of the work here this week so far is on CLI, XNAT/REST API, and DICOM. http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 -Steve On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter > wrote: Hi JC, Yes, it seems to have solved our CTK build problem. The reason I was asking about opinions is that I don't know what repercussions it may have on other platforms. If it seems OK the I'd appreciate propagating it to the CTK core or ITK. I can create a CTK topic branch containing the change if it makes the process easier. Thanks, csaba From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: November 4, 2013 09:30 To: Csaba Pinter Cc: pieper at bwh.harvard.edu; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Based on your entry in the CTK tracker. I am assuming it is good to go ? See https://github.com/commontk/CTK/issues/382 On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin > wrote: Hi Csaba, After you confirm that adding NO_DEFAULT_PATH to [1] works. I will coordinate with ITK folks so that they also update their FindDCMTK.cmake file. Thanks Jc [1] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter > wrote: Hi Steve, I was going to do just that, thanks for the reminder! I created issue https://github.com/commontk/CTK/issues/382. The main reason I haven't created a topic branch yet is that I would like to hear some opinions about it first, as I don't know what consequences it has on Linux and Mac. FYI my agenda for next week besides this small change is to try our display tables and DICOM roles enhancement for the DICOM browser (that Andras and I implemented during the last hackfest) against the latest listview-based browser and integrate it if it turns out to be working fine. Thanks, csaba From: Steve Pieper [mailto:pieper at ibility.net] Sent: October 31, 2013 16:37 To: Csaba Pinter Cc: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba - We'll be discussing open issues next week in London - can you make sure there's a ctk issue that points to your assembla report? http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday Thanks, Steve On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter > wrote: Hi there, Any thoughts about the FindDCMTK changes proposed below? I'd appreciate any feedback. Thanks, csaba From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Csaba Pinter Sent: October 10, 2013 15:14 To: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hello, I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and now I could successfully build CTK with DCMTK. As we have the same issue from time to time with CTK in Slicer (but finally we could reproduce it, see [1]), I propose adding this flag to FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake change is not integrated to DCMTK. As my CMake knowledge is limited, I don't know if this change causes any problem on other operating systems though. I'd appreciate to hear your opinions about this. Thank you, csaba [1] https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: October 4, 2013 18:34 To: Csaba Pinter Cc: Andras Lasso; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, As illustrated in the enclosed screenshot, build tree can be exported into the CMake package registry. As some point, the DCMTK build tree has probably been exported [1][2][3]. Since when building CTK, it is expected that there are no DCMTKConfig.cmake available, the first should be failing. In your case, it seems not to be failing because it resolves to that previous build added to the registery. I would suggest to try adding the parameter "NO_DEFAULT_PATH" to the FindDCMTK.cmake module available in CTK. See [4] Hth Jc [1] http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export [2] http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html [3] https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 [4] https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter > wrote: Hi Jc, I tried building CTK in many ways, but the result is always the same, so the problem is completely reproducible, at least on my computer (I haven't tried it elsewhere yet, but I plan to). As we have been struggling with this issue for quite a while, but haven't been able to consistently reproduce it, this is a great opportunity to fix it once and for all. I did some digging and this is what I found: - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in the incorrect directory that is used later (in one of my slicer builds) - The reason why the DCMTK downloaded by the superbuild is not found is most probably that it is a version that doesn't have DCMTKConfig.cmake (as you described earlier) - The same thing (finding the wrong DCMTK) happens if I add NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake Now I don't have any idea how to get the superbuild to use its own DCMTK. Also even if I can do a workaround and have a good build of CTK on my machine, this is an issue that other people who want to build CTK on Windows while already having a Slicer build have to face. Cheers, csaba From: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Sent: October 4, 2013 12:07 To: Andras Lasso Cc: Csaba Pinter; CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, Andras, Within the file FindDCMTK.cmake [1] provided by CTK, where would you suggest to add the NO_CMAKE_BUILDS_PATH ? Let's also note that the FindDCMTK.cmake provided by ITK would have to patched also ... If you can reproduce the problem, with a combination of clearing cache + adding some "message()" statement, you should be able to find out or confirm what is the source of the problem. Jc [1] https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso > wrote: I have this annoying issue during Slicer builds as well: my nightly slicer builds usually break after a few days because after I configure other projects in CMake CTK finds DCMTK of another project instead of its own. It may be due to the find_package path finding rule 5: ?Search project build trees recently configured in a CMake GUI. This can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is building multiple dependent projects one after another.? (http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK should rely on rules 1-4 or disable rule 5 ? or it may be possible that something else goes wrong and that?s why the rule 5 kicks in. Andras From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Jean-Christophe Fillion-Robin Sent: Wednesday, October 02, 2013 11:39 AM To: Csaba Pinter Cc: CTK mailing list Subject: Re: [Ctk-developers] DCMTK_DIR is found incorrectly Hi Csaba, In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global variable that is empty by default. On the other hand "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" SET(CTK_CMAKE_UTILITIES_DIR "/home/jchris/Projects/CTK/Utilities/CMake") Otherwise, you will find below the result of my experiment. When configured, CTK found the expected DCMTK. On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package "python2.7-dev" doing so the following works. Note that I didn't enable CTK_ENABLE_ALL since I didn't the build system to build VTK or ITK components. Instead, I passed the following options: -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON -DCTK_BUILD_EXAMPLES $ git clone git at github.com:commontk/CTK $ mkdir CTK-Debug $ cd CTK-Debug $ cmake -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK [...] -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR ( CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] evaluates to True -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Backend/LocalProcess] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_CommandLineModules/Core] required by [ctkCommandLineModuleExplorer] -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by [ctkSimplePythonShell] -- Enabling option [CTK_LIB_Scripting/Python/Core] required by [ctkSimplePythonShell] -- Found PythonInterp: /usr/bin/python (found version "2.7.4") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.4") -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml -- Found Git: /usr/bin/git (found version "1.8.1.2") -- Configuring done -- Generating done -- Build files have been written to: /home/jchris/Projects/CTK-Debug $ make -j6 [...] [ 90%] Performing configure step for 'CTK-Configure' [...] -- Found PythonInterp: /usr/bin/python (found version "2.7.4") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.4") -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml -- Trying to find DCMTK expecting DCMTKConfig.cmake -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed -- Trying to find DCMTK relying on FindDCMTK.cmake -- Looking for include file pthread.h -- Looking fothe r include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Found DCMTK: /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config -- Trying to find DCMTK relying on FindDCMTK.cmake - ok -- CTKCore: BFD support disabled -- Configuring done -- Generating done [...] -- Build files have been written to: /home/jchris/Projects/CTK-Debug/CTK-build [...] [100%] Built target CTKWidgetsCppTests [100%] Built target CTK-build $ cd CTK-build $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, this is explained by the fact the official DCMTK didn't integrate yet our latest and greatest contribution [1] Hth Jc [1] https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter > wrote: Hi all, I'm trying to build CTK separately, but I have problems with linking DCMTK. The way I build CTK: - Turn on CTK_BUILD_ALL - Turn on CTK_ENABLE_DICOM (I need this as I want to merge and test my changes in the CTK/Core/DICOM project) - Set the qmake executable - Configure - CMake complains about python paths, I set those manually - Configure, Generate - Build superbuild Then DCMTK is downloaded and built by the superbuild, but later on, CTK projects find a completely different DCMTK directory (in my Slicer nightly build directory). I tried to manually add the DCMTK directory to CMake, but this variable does not exist in the superbuild (it is also not passed down), and setting it to the inner CTK project doesn't work. Basically no matter what I do, the DCMTK path is set to whatever find_project finds. This is what I found in CTKConfig.cmake: # Update CMake module path so that calling "find_package(DCMTK)" works as expected # after calling "find_package(CTK)" # Ideally projects like DCMTK or PythonQt should provide both "Config" and "Use" files. set(CMAKE_MODULE_PATH ${CTK_CMAKE_UTILITIES_DIR} ${CMAKE_MODULE_PATH} ) Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so there is no chance DCMTK is found correctly. Can someone please help with this? Thanks a lot, csaba ________________________________ Csaba Pinter Medical Software Systems Engineer Laboratory for Percutanous Surgery School of Computing Queen?s University Kingston, ON, Canada Email: csaba.pinter at queensu.ca Web: http://perk.cs.queensu.ca _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -- +1 919 869 8849 -- +1 919 869 8849 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -- +1 919 869 8849 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From pieper at ibility.net Tue Nov 5 15:02:11 2013 From: pieper at ibility.net (Steve Pieper) Date: Tue, 5 Nov 2013 10:02:11 -0500 Subject: [Ctk-developers] hackfest hangout Message-ID: Let's try this link - if you can't get in, send an email: https://plus.google.com/hangouts/_/72cpj9cgtu4ts7s2a382vaabbo?hl=en -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Nov 5 17:56:18 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 5 Nov 2013 12:56:18 -0500 Subject: [Ctk-developers] CTK Google Plus community (was: Re: DCMTK_DIR is found incorrectly) In-Reply-To: References: Message-ID: Here it is :) See https://plus.google.com/u/0/communities/105094033241300780178 On Mon, Nov 4, 2013 at 1:08 PM, Steve Pieper wrote: > Sounds like a consistent naming convention :) > > > On Mon, Nov 4, 2013 at 12:00 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> I propose to name the community "CTK BarCamp". See >> http://en.wikipedia.org/wiki/BarCamp >> >> What do you think ? >> >> >> On Mon, Nov 4, 2013 at 11:33 AM, Steve Pieper wrote: >> >>> Would probably help with the multiple timezones too... >>> >>> >>> On Mon, Nov 4, 2013 at 11:18 AM, Jean-Christophe Fillion-Robin < >>> jchris.fillionr at kitware.com> wrote: >>> >>>> Creating the event on G+ automatically add it to my calendar :) >>>> >>>> May be we could create a CommonTK Google plus community ? >>>> >>>> >>>> On Mon, Nov 4, 2013 at 11:16 AM, Steve Pieper wrote: >>>> >>>>> I was planning to just start the hangout and then email the link - do >>>>> you find that scheduling the event has advantages? Wouldn't we need a ctk >>>>> google group or something? >>>>> >>>>> Talk to you tomorrow, >>>>> -Steve >>>>> >>>>> >>>>> On Mon, Nov 4, 2013 at 11:12 AM, Jean-Christophe Fillion-Robin < >>>>> jchris.fillionr at kitware.com> wrote: >>>>> >>>>>> Works for me. Could you create a Google event/hangout ? >>>>>> Talk to you tomorrow, >>>>>> Jc >>>>>> >>>>>> >>>>>> On Mon, Nov 4, 2013 at 11:04 AM, Steve Pieper wrote: >>>>>> >>>>>>> Hi Csaba - >>>>>>> >>>>>>> Andreas is here and working on some of the coding input from Julien >>>>>>> (but the emails to him from the CTK list aren't working right now for some >>>>>>> reason). >>>>>>> >>>>>>> -Steve >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 4, 2013 at 10:21 AM, Csaba Pinter < >>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>> >>>>>>>> Hi Steve, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Definitely, I can join the hangout tomorrow. Thanks for discussing >>>>>>>> the issue! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Are the DKFZ fellas going to work on the list-based DICOM browser? >>>>>>>> We'd like to at least start integrating the display database and DICOM >>>>>>>> roles we implemented last time. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>>>>> *Sent:* November 4, 2013 10:02 >>>>>>>> *To:* Csaba Pinter >>>>>>>> *Cc:* Jean-Christophe Fillion-Robin; CTK mailing list >>>>>>>> >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Csaba, Jc - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> London calling (always wanted to say that). We talked over the >>>>>>>> issue a bit and didn't see any obvious issues but there was a request from >>>>>>>> some folks for a further discussion of the underlying issue so we put it on >>>>>>>> the agenda for a Tuesday afternoon (15:00 London time) hangout. Does that >>>>>>>> work for you two? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Most of the work here this week so far is on CLI, XNAT/REST API, >>>>>>>> and DICOM. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Steve >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 4, 2013 at 9:34 AM, Csaba Pinter < >>>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>>> >>>>>>>> Hi JC, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, it seems to have solved our CTK build problem. The reason I >>>>>>>> was asking about opinions is that I don't know what repercussions it may >>>>>>>> have on other platforms. >>>>>>>> >>>>>>>> If it seems OK the I'd appreciate propagating it to the CTK core or >>>>>>>> ITK. I can create a CTK topic branch containing the change if it makes the >>>>>>>> process easier. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>>>>> jchris.fillionr at kitware.com] >>>>>>>> *Sent:* November 4, 2013 09:30 >>>>>>>> *To:* Csaba Pinter >>>>>>>> *Cc:* pieper at bwh.harvard.edu; CTK mailing list >>>>>>>> >>>>>>>> >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Based on your entry in the CTK tracker. I am assuming it is good to >>>>>>>> go ? >>>>>>>> See https://github.com/commontk/CTK/issues/382 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 4, 2013 at 9:28 AM, Jean-Christophe Fillion-Robin < >>>>>>>> jchris.fillionr at kitware.com> wrote: >>>>>>>> >>>>>>>> Hi Csaba, >>>>>>>> >>>>>>>> After you confirm that adding NO_DEFAULT_PATH to [1] works. I will >>>>>>>> coordinate with ITK folks so that they also update their FindDCMTK.cmake >>>>>>>> file. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Jc >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 31, 2013 at 4:46 PM, Csaba Pinter < >>>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>>> >>>>>>>> Hi Steve, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I was going to do just that, thanks for the reminder! >>>>>>>> >>>>>>>> I created issue https://github.com/commontk/CTK/issues/382. >>>>>>>> >>>>>>>> The main reason I haven't created a topic branch yet is that I >>>>>>>> would like to hear some opinions about it first, as I don't know what >>>>>>>> consequences it has on Linux and Mac. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> FYI my agenda for next week besides this small change is to try our >>>>>>>> display tables and DICOM roles enhancement for the DICOM browser (that >>>>>>>> Andras and I implemented during the last hackfest) against the latest >>>>>>>> listview-based browser and integrate it if it turns out to be working fine. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Steve Pieper [mailto:pieper at ibility.net] >>>>>>>> *Sent:* October 31, 2013 16:37 >>>>>>>> >>>>>>>> >>>>>>>> *To:* Csaba Pinter >>>>>>>> *Cc:* CTK mailing list >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Csaba - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We'll be discussing open issues next week in London - can you make >>>>>>>> sure there's a ctk issue that points to your assembla report? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013#Monday >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 17, 2013 at 11:02 AM, Csaba Pinter < >>>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Any thoughts about the FindDCMTK changes proposed below? >>>>>>>> >>>>>>>> I'd appreciate any feedback. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Csaba Pinter >>>>>>>> *Sent:* October 10, 2013 15:14 >>>>>>>> *To:* CTK mailing list >>>>>>>> >>>>>>>> >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I tried the NO_DEFAULT_PATH idea Jc was suggesting (see below), and >>>>>>>> now I could successfully build CTK with DCMTK. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As we have the same issue from time to time with CTK in Slicer (but >>>>>>>> finally we could reproduce it, see [1]), I propose adding this flag to >>>>>>>> FindDCMTK.cmake in the CTK master, at least until the DCMTKConfig.cmake >>>>>>>> change is not integrated to DCMTK. >>>>>>>> >>>>>>>> As my CMake knowledge is limited, I don't know if this change >>>>>>>> causes any problem on other operating systems though. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'd appreciate to hear your opinions about this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://www.assembla.com/spaces/slicerrt/tickets/325#/activity/ticket >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Jean-Christophe Fillion-Robin [ >>>>>>>> mailto:jchris.fillionr at kitware.com ] >>>>>>>> *Sent:* October 4, 2013 18:34 >>>>>>>> *To:* Csaba Pinter >>>>>>>> *Cc:* Andras Lasso; CTK mailing list >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Csaba, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As illustrated in the enclosed screenshot, build tree can be >>>>>>>> exported into the CMake package registry. As some point, the DCMTK build >>>>>>>> tree has probably been exported [1][2][3]. >>>>>>>> >>>>>>>> Since when building CTK, it is expected that there are no >>>>>>>> DCMTKConfig.cmake available, the first should be failing. In your case, it >>>>>>>> seems not to be failing because it resolves to that previous build added to >>>>>>>> the registery. >>>>>>>> >>>>>>>> I would suggest to try adding the parameter "NO_DEFAULT_PATH" to >>>>>>>> the FindDCMTK.cmake module available in CTK. See [4] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hth >>>>>>>> >>>>>>>> Jc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:export >>>>>>>> [2] >>>>>>>> http://slicer-devel.65872.n3.nabble.com/Packaging-seems-to-work-again-tp4028121p4028134.html >>>>>>>> >>>>>>>> [3] >>>>>>>> https://www.assembla.com/spaces/slicerrt/tickets/244-dcmtk_dir-vs--dcmtkconfig-cmake?comment=267984263#comment:267984263 >>>>>>>> >>>>>>>> [4] >>>>>>>> https://github.com/commontk/CTK/blob/f64b68acd717dab060db41e8bee3f0f30df1a58f/Utilities/CMake/FindDCMTK.cmake#L42 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 4, 2013 at 5:39 PM, Csaba Pinter < >>>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>>> >>>>>>>> Hi Jc, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I tried building CTK in many ways, but the result is always the >>>>>>>> same, so the problem is completely reproducible, at least on my computer (I >>>>>>>> haven't tried it elsewhere yet, but I plan to). As we have been struggling >>>>>>>> with this issue for quite a while, but haven't been able to consistently >>>>>>>> reproduce it, this is a great opportunity to fix it once and for all. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I did some digging and this is what I found: >>>>>>>> >>>>>>>> - FindDCMTK.cmake finds DCMTKConfig.cmake, but it is in >>>>>>>> the incorrect directory that is used later (in one of my slicer builds) >>>>>>>> >>>>>>>> - The reason why the DCMTK downloaded by the superbuild >>>>>>>> is not found is most probably that it is a version that doesn't have >>>>>>>> DCMTKConfig.cmake (as you described earlier) >>>>>>>> >>>>>>>> - The same thing (finding the wrong DCMTK) happens if I >>>>>>>> add NO_CMAKE_BUILDS_PATH to the find_package call in FindDCMTK.cmake >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Now I don't have any idea how to get the superbuild to use its own >>>>>>>> DCMTK. >>>>>>>> >>>>>>>> Also even if I can do a workaround and have a good build of CTK on >>>>>>>> my machine, this is an issue that other people who want to build CTK on >>>>>>>> Windows while already having a Slicer build have to face. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Jean-Christophe Fillion-Robin [mailto: >>>>>>>> jchris.fillionr at kitware.com] >>>>>>>> *Sent:* October 4, 2013 12:07 >>>>>>>> *To:* Andras Lasso >>>>>>>> *Cc:* Csaba Pinter; CTK mailing list >>>>>>>> >>>>>>>> >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Csaba, Andras, >>>>>>>> >>>>>>>> Within the file FindDCMTK.cmake [1] provided by CTK, where would >>>>>>>> you suggest to add the NO_CMAKE_BUILDS_PATH ? >>>>>>>> >>>>>>>> Let's also note that the FindDCMTK.cmake provided by ITK would have >>>>>>>> to patched also ... >>>>>>>> >>>>>>>> If you can reproduce the problem, with a combination of clearing >>>>>>>> cache + adding some "message()" statement, you should be able to find out >>>>>>>> or confirm what is the source of the problem. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jc >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 2, 2013 at 1:42 PM, Andras Lasso >>>>>>>> wrote: >>>>>>>> >>>>>>>> I have this annoying issue during Slicer builds as well: my nightly >>>>>>>> slicer builds usually break after a few days because after I configure >>>>>>>> other projects in CMake CTK finds DCMTK of another project instead of its >>>>>>>> own. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It may be due to the find_package path finding rule 5: ?Search >>>>>>>> project build trees recently configured in a CMake GUI. This can be skipped >>>>>>>> if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user >>>>>>>> is building multiple dependent projects one after another.? ( >>>>>>>> http://www.cmake.org/cmake/help/v2.8.10/ctest.html). Probably CTK >>>>>>>> should rely on rules 1-4 or disable rule 5 ? or it may be possible that >>>>>>>> something else goes wrong and that?s why the rule 5 kicks in. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Andras >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* ctk-developers-bounces at commontk.org [mailto: >>>>>>>> ctk-developers-bounces at commontk.org] *On Behalf Of *Jean-Christophe >>>>>>>> Fillion-Robin >>>>>>>> *Sent:* Wednesday, October 02, 2013 11:39 AM >>>>>>>> >>>>>>>> >>>>>>>> *To:* Csaba Pinter >>>>>>>> *Cc:* CTK mailing list >>>>>>>> *Subject:* Re: [Ctk-developers] DCMTK_DIR is found incorrectly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Csaba, >>>>>>>> >>>>>>>> In CTKConfig, the variable "CMAKE_MODULE_PATH" is a CMake global >>>>>>>> variable that is empty by default. On the other hand >>>>>>>> "CTK_CMAKE_UTILITIES_DIR" should not be empty as illustrated below: >>>>>>>> >>>>>>>> $ cat ../CTKConfig.cmake | ack -i "set\(CTK_CMAKE_UTILITIES_DIR" >>>>>>>> SET(CTK_CMAKE_UTILITIES_DIR >>>>>>>> "/home/jchris/Projects/CTK/Utilities/CMake") >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Otherwise, you will find below the result of my experiment. When >>>>>>>> configured, CTK found the expected DCMTK. >>>>>>>> >>>>>>>> >>>>>>>> On Ubuntu 13.04 using CMake 2.8.11.2, after installing the package >>>>>>>> "python2.7-dev" doing so the following works. >>>>>>>> >>>>>>>> Note that I didn't enable CTK_ENABLE_ALL since I didn't the build >>>>>>>> system to build VTK or ITK components. Instead, I passed the following >>>>>>>> options: >>>>>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON >>>>>>>> -DCTK_ENABLE_DICOM:BOOL=ON >>>>>>>> -DCTK_BUILD_EXAMPLES >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> $ git clone git at github.com:commontk/CTK >>>>>>>> >>>>>>>> $ mkdir CTK-Debug >>>>>>>> >>>>>>>> $ cd CTK-Debug >>>>>>>> >>>>>>>> $ cmake >>>>>>>> -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Support/QtSDK-1.2.1/Desktop/Qt/4.8.1/gcc/bin/qmake >>>>>>>> -DCTK_ENABLE_Python_Wrapping:BOOL=ON -DCTK_ENABLE_DICOM:BOOL=ON >>>>>>>> -DCTK_BUILD_EXAMPLES:BOOL=ON ../CTK >>>>>>>> [...] >>>>>>>> -- Enabling [CTK_LIB_DICOM/Core] because of [ CTK_ENABLE_DICOM:1 OR >>>>>>>> ( CTK_ENABLE_DICOMApplicationHosting:0 AND CTK_BUILD_EXAMPLES:1 )] >>>>>>>> evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOM] because of [ CTK_ENABLE_DICOM:1 AND >>>>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOM2] because of [ CTK_ENABLE_DICOM:1 AND >>>>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOMIndexer] because of [ >>>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOMDemoSCU] because of [ >>>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOMQuery] because of [ CTK_ENABLE_DICOM:1 >>>>>>>> AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOMRetrieve] because of [ >>>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOMQueryRetrieve] because of [ >>>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkCommandLineModuleExplorer] because of [ >>>>>>>> CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkDICOMObjectViewer] because of [ >>>>>>>> CTK_ENABLE_DICOM:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Enabling [CTK_APP_ctkSimplePythonShell] because of [ >>>>>>>> CTK_ENABLE_Python_Wrapping:1 AND CTK_BUILD_EXAMPLES:1] evaluates to True >>>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput-alldep.txt >>>>>>>> -- Generated: >>>>>>>> /home/jchris/Projects/CTK-Debug/DGraphInput-alldep-withext.txt >>>>>>>> -- Enabling option [CTK_LIB_DICOM/Widgets] required by [ctkDICOM] >>>>>>>> -- Enabling option [CTK_LIB_Widgets] required by [ctkDICOM] >>>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtGui] >>>>>>>> required by [ctkCommandLineModuleExplorer] >>>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Frontend/QtWebKit] >>>>>>>> required by [ctkCommandLineModuleExplorer] >>>>>>>> -- Enabling option >>>>>>>> [CTK_LIB_CommandLineModules/Backend/LocalProcess] required by >>>>>>>> [ctkCommandLineModuleExplorer] >>>>>>>> -- Enabling option >>>>>>>> [CTK_LIB_CommandLineModules/Backend/FunctionPointer] required by >>>>>>>> [ctkCommandLineModuleExplorer] >>>>>>>> -- Enabling option [CTK_LIB_CommandLineModules/Core] required by >>>>>>>> [ctkCommandLineModuleExplorer] >>>>>>>> -- Enabling option [CTK_LIB_Scripting/Python/Widgets] required by >>>>>>>> [ctkSimplePythonShell] >>>>>>>> -- Enabling option [CTK_LIB_Scripting/Python/Core] required by >>>>>>>> [ctkSimplePythonShell] >>>>>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so(found version "2.7.4") >>>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/DGraphInput.txt >>>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/Project.xml >>>>>>>> -- Found Git: /usr/bin/git (found version "1.8.1.2") >>>>>>>> -- Configuring done >>>>>>>> -- Generating done >>>>>>>> -- Build files have been written to: /home/jchris/Projects/CTK-Debug >>>>>>>> >>>>>>>> $ make -j6 >>>>>>>> [...] >>>>>>>> [ 90%] Performing configure step for 'CTK-Configure' >>>>>>>> [...] >>>>>>>> -- Found PythonInterp: /usr/bin/python (found version "2.7.4") >>>>>>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so(found version "2.7.4") >>>>>>>> -- Generated: >>>>>>>> /home/jchris/Projects/CTK-Debug/CTK-build/DGraphInput.txt >>>>>>>> -- Generated: /home/jchris/Projects/CTK-Debug/CTK-build/Project.xml >>>>>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake >>>>>>>> -- Trying to find DCMTK expecting DCMTKConfig.cmake - failed >>>>>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake >>>>>>>> -- Looking for include file pthread.h >>>>>>>> -- Looking fothe r include file pthread.h - found >>>>>>>> -- Looking for pthread_create >>>>>>>> -- Looking for pthread_create - not found >>>>>>>> -- Looking for pthread_create in pthreads >>>>>>>> -- Looking for pthread_create in pthreads - not found >>>>>>>> -- Looking for pthread_create in pthread >>>>>>>> -- Looking for pthread_create in pthread - found >>>>>>>> -- Found Threads: TRUE >>>>>>>> -- Found DCMTK: >>>>>>>> /home/jchris/Projects/CTK-Debug/CMakeExternals/Install/include/dcmtk/config >>>>>>>> >>>>>>>> -- Trying to find DCMTK relying on FindDCMTK.cmake - ok >>>>>>>> -- CTKCore: BFD support disabled >>>>>>>> -- Configuring done >>>>>>>> -- Generating done >>>>>>>> [...] >>>>>>>> -- Build files have been written to: >>>>>>>> /home/jchris/Projects/CTK-Debug/CTK-build >>>>>>>> >>>>>>>> [...] >>>>>>>> [100%] Built target CTKWidgetsCppTests >>>>>>>> [100%] Built target CTK-build >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> $ cd CTK-build >>>>>>>> $ $ cat CMakeCache.txt | ack DCMTK_DIR\:PATH >>>>>>>> >>>>>>>> DCMTK_DIR:PATH=/home/jchris/Projects/CTK-Debug/CMakeExternals/Install >>>>>>>> >>>>>>>> Let's note that DCMTK couldn't be found using DCMTKConfig.cmake, >>>>>>>> this is explained by the fact the official DCMTK didn't integrate yet our >>>>>>>> latest and greatest contribution [1] >>>>>>>> >>>>>>>> Hth >>>>>>>> >>>>>>>> Jc >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 2, 2013 at 10:18 AM, Csaba Pinter < >>>>>>>> csaba.pinter at queensu.ca> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'm trying to build CTK separately, but I have problems with >>>>>>>> linking DCMTK. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The way I build CTK: >>>>>>>> >>>>>>>> - Turn on CTK_BUILD_ALL >>>>>>>> >>>>>>>> - Turn on CTK_ENABLE_DICOM (I need this as I want to >>>>>>>> merge and test my changes in the CTK/Core/DICOM project) >>>>>>>> >>>>>>>> - Set the qmake executable >>>>>>>> >>>>>>>> - Configure >>>>>>>> >>>>>>>> - CMake complains about python paths, I set those manually >>>>>>>> >>>>>>>> - Configure, Generate >>>>>>>> >>>>>>>> - Build superbuild >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Then DCMTK is downloaded and built by the superbuild, but later on, >>>>>>>> CTK projects find a completely different DCMTK directory (in my Slicer >>>>>>>> nightly build directory). I tried to manually add the DCMTK directory to >>>>>>>> CMake, but this variable does not exist in the superbuild (it is also not >>>>>>>> passed down), and setting it to the inner CTK project doesn't work. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Basically no matter what I do, the DCMTK path is set to whatever >>>>>>>> find_project finds. This is what I found in CTKConfig.cmake: >>>>>>>> >>>>>>>> # Update CMake module path so that calling "find_package(DCMTK)" >>>>>>>> works as expected >>>>>>>> >>>>>>>> # after calling "find_package(CTK)" >>>>>>>> >>>>>>>> # Ideally projects like DCMTK or PythonQt should provide both >>>>>>>> "Config" and "Use" files. >>>>>>>> >>>>>>>> set(CMAKE_MODULE_PATH >>>>>>>> >>>>>>>> ${CTK_CMAKE_UTILITIES_DIR} >>>>>>>> >>>>>>>> ${CMAKE_MODULE_PATH} >>>>>>>> >>>>>>>> ) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Now the problem with this is that ${CMAKE_MODULE_PATH} is empty, so >>>>>>>> there is no chance DCMTK is found correctly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Can someone please help with this? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks a lot, >>>>>>>> >>>>>>>> csaba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> Csaba Pinter >>>>>>>> >>>>>>>> Medical Software Systems Engineer >>>>>>>> >>>>>>>> Laboratory for Percutanous Surgery >>>>>>>> >>>>>>>> School of Computing >>>>>>>> >>>>>>>> Queen?s University >>>>>>>> >>>>>>>> Kingston, ON, Canada >>>>>>>> >>>>>>>> Email: csaba.pinter at queensu.ca >>>>>>>> >>>>>>>> Web: http://perk.cs.queensu.ca >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ctk-developers mailing list >>>>>>>> Ctk-developers at commontk.org >>>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> +1 919 869 8849 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> +1 919 869 8849 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> +1 919 869 8849 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ctk-developers mailing list >>>>>>>> Ctk-developers at commontk.org >>>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>>> >>>>>>>> >>>>>>>> The information in this e-mail is intended only for the person to >>>>>>>> whom it is >>>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>>> the e-mail >>>>>>>> contains patient information, please contact the Partners >>>>>>>> Compliance HelpLine at >>>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>>>> you in error >>>>>>>> but does not contain patient information, please contact the sender >>>>>>>> and properly >>>>>>>> dispose of the e-mail. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ctk-developers mailing list >>>>>>>> Ctk-developers at commontk.org >>>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> +1 919 869 8849 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> +1 919 869 8849 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +1 919 869 8849 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> +1 919 869 8849 >>>> >>> >>> >> >> >> -- >> +1 919 869 8849 >> > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Wed Nov 6 22:43:37 2013 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 6 Nov 2013 17:43:37 -0500 Subject: [Ctk-developers] Debian builds of ITK for non-x84/amd64 architectures Message-ID: Hi Steve, Dominique, Marco, [list-cross-post] Jean-Christophe noted this bug [1] at the CTK hackfest, which is blocking CTK for other architectures. Is it possible to get some of these architectures reporting nightly builds [2] to the ITK software quality dashboard [3], so they can be cleaned up? Thanks, Matt [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711 [2] http://www.itk.org/Wiki/ITK/Git/Dashboard [3] http://open.cdash.org/index.php?project=Insight From domibel at debian.org Thu Nov 7 01:14:49 2013 From: domibel at debian.org (Dominique Belhachemi) Date: Wed, 6 Nov 2013 20:14:49 -0500 Subject: [Ctk-developers] Debian builds of ITK for non-x84/amd64 architectures In-Reply-To: References: Message-ID: Hi Matt, Thank you for looking into this. Per Debian policy the build machines cannot submit any build reports, but you can get all build logs (with all failing tests) here: https://buildd.debian.org/status/logs.php?pkg=insighttoolkit4 I see that the ITK build time on Debian's build machines can take up to 3 days. So it might be worth to setup a local build machine in your office. Luis did something similar a while ago: Cross Compiling ITK for Raspberry Pi http://www.kitware.com/blog/home/post/428 Google Chromebook likes ITK with Crouton http://www.kitware.com/blog/home/post/532 It is good to fix build issues on those platforms, but given the very long build time I support Steve's decision to support only popular architectures. Cheers -Dominique On Wed, Nov 6, 2013 at 5:43 PM, Matt McCormick wrote: > Hi Steve, Dominique, Marco, [list-cross-post] > > Jean-Christophe noted this bug [1] at the CTK hackfest, which is > blocking CTK for other architectures. Is it possible to get some of > these architectures reporting nightly builds [2] to the ITK software > quality dashboard [3], so they can be cleaned up? > > Thanks, > Matt > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711 > [2] http://www.itk.org/Wiki/ITK/Git/Dashboard > [3] http://open.cdash.org/index.php?project=Insight > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Thu Nov 7 04:43:54 2013 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 6 Nov 2013 23:43:54 -0500 Subject: [Ctk-developers] Debian builds of ITK for non-x84/amd64 architectures In-Reply-To: <8318445.RIIFzQxy2e@riemann> References: <8318445.RIIFzQxy2e@riemann> Message-ID: - re-send with address for lists - Hi Dominique and Steve, > As Dominique mentioned, policy for the official build daemon machines forbids > network access from the build. So, a while back, I asked around for some > other machines to use for nightly builds. I got a couple of offers of a login, > but I lacked the time to set up and maintain the nightly. Thanks for the information here. It is good to have both an understanding of Debian's build machine policies, and a link to the current builds. A lack of fast enough hardware for these architectures is a challenge. The cross architecture build system that Debian has set up is impressive. For some of these architectures, cross-compiling with limited testing on the native architecture may be the only feasible option, but that requires extra build configuration. > > The other hard truth is that having a nightly build is not enough. Each > architecture needs a champion who will investigate the failures, do extra > testing or develop patches. The ITK community won't do it on their own. Even > with a nightly build submitted to cdash. > > I'm willing to help out with advice but I simply lack the time to do very much > follow-up for non-mainstream architectures. Truthfully, I don't have much > time even for amd64 so more blood for Debian packaging would be welcome! Yes! Thanks for your much appreciated work. Matt On Wed, Nov 6, 2013 at 10:31 PM, Steve M. Robbins wrote: > Hello Matt, > > On November 6, 2013 05:43:37 PM Matt McCormick wrote: > >> Jean-Christophe noted this bug [1] at the CTK hackfest, which is >> blocking CTK for other architectures. Is it possible to get some of >> these architectures reporting nightly builds [2] to the ITK software >> quality dashboard [3], so they can be cleaned up? > > It's a great idea in principle for all the debian architectures to submit to > the ITK dashboard -- and now that we're down to just two, we do have full > coverage! :-) > > If we want better coverage, the hard truth is that we need more volunteers and > on a sustained basis. > > As Dominique mentioned, policy for the official build daemon machines forbids > network access from the build. So, a while back, I asked around for some > other machines to use for nightly builds. I got a couple of offers of a login, > but I lacked the time to set up and maintain the nightly. > > The other hard truth is that having a nightly build is not enough. Each > architecture needs a champion who will investigate the failures, do extra > testing or develop patches. The ITK community won't do it on their own. Even > with a nightly build submitted to cdash. > > I'm willing to help out with advice but I simply lack the time to do very much > follow-up for non-mainstream architectures. Truthfully, I don't have much > time even for amd64 so more blood for Debian packaging would be welcome! > > Cheers, > -Steve From pieper at ibility.net Thu Nov 7 19:49:23 2013 From: pieper at ibility.net (Steve Pieper) Date: Thu, 7 Nov 2013 14:49:23 -0500 Subject: [Ctk-developers] new dicom interface Message-ID: Hello from the CTK hackfest in London! [1] For a while now several of groups have been working on improving the dicom browser in CTK (the one used in the Slicer DICOM module) to make it more consistent with clinical systems and to make it easier to customize. Work really got going at the last hackfest at Queens in Kingston [2] where a design was worked out that would help with a number of longstanding issues faced in SlicerRT [for example, 3] and some issues intrinsic to the way the old DICOM tree view was implemented [4]. After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new interface to address these issues. Plus Alireza Mehrtash of BWH has added a DICOM header browser option to address a longstanding missing feature of slicer4 [5]. These have now been integrated into the slicer trunk [6] and the new interface is documented on the nightly section of the wiki [7]. Of course this big of a change may take a little time to settle out, so please let us know if you see build or run time issues. Suggestions are welcome too. Cheers from jolly old England, Steve [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 [2] http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database_and_Networking [3] http://na-mic.org/Bug/view.php?id=2828 [4] http://na-mic.org/Bug/view.php?id=3106 [5] http://na-mic.org/Bug/view.php?id=1838 [6] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22689 [7] http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/DICOM -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Nov 7 20:52:27 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 7 Nov 2013 15:52:27 -0500 Subject: [Ctk-developers] new dicom interface In-Reply-To: References: Message-ID: Hi Steve, Impressive work ! And great documentation page :) Thanks Jc Ps: Should the change be added to [2] instead of [1] [1] http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/DICOM [2] http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/DICOM On Thu, Nov 7, 2013 at 2:49 PM, Steve Pieper wrote: > Hello from the CTK hackfest in London! [1] > > For a while now several of groups have been working on improving the dicom > browser in CTK (the one used in the Slicer DICOM module) to make it more > consistent with clinical systems and to make it easier to customize. Work > really got going at the last hackfest at Queens in Kingston [2] where a > design was worked out that would help with a number of longstanding issues > faced in SlicerRT [for example, 3] and some issues intrinsic to the way the > old DICOM tree view was implemented [4]. > > After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden of > DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new > interface to address these issues. Plus Alireza Mehrtash of BWH has added > a DICOM header browser option to address a longstanding missing feature of > slicer4 [5]. These have now been integrated into the slicer trunk [6] and > the new interface is documented on the nightly section of the wiki [7]. > > Of course this big of a change may take a little time to settle out, so > please let us know if you see build or run time issues. Suggestions are > welcome too. > > Cheers from jolly old England, > Steve > > > [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 > > [2] > http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database_and_Networking > > [3] http://na-mic.org/Bug/view.php?id=2828 > > [4] http://na-mic.org/Bug/view.php?id=3106 > > [5] http://na-mic.org/Bug/view.php?id=1838 > > [6] > http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22689 > > [7] > http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/DICOM > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Fri Nov 8 08:45:41 2013 From: pieper at ibility.net (Steve Pieper) Date: Fri, 8 Nov 2013 03:45:41 -0500 Subject: [Ctk-developers] new dicom interface In-Reply-To: References: Message-ID: Ah - good catch Jc! - I just swapped the documentation so now the Nightly link (your [2]) describes the new interface. -Steve On Thu, Nov 7, 2013 at 3:52 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Steve, > > Impressive work ! And great documentation page :) > > Thanks > Jc > > Ps: Should the change be added to [2] instead of [1] > > [1] > http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/DICOM > [2] > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/DICOM > > > On Thu, Nov 7, 2013 at 2:49 PM, Steve Pieper wrote: > >> Hello from the CTK hackfest in London! [1] >> >> For a while now several of groups have been working on improving the >> dicom browser in CTK (the one used in the Slicer DICOM module) to make it >> more consistent with clinical systems and to make it easier to customize. >> Work really got going at the last hackfest at Queens in Kingston [2] where >> a design was worked out that would help with a number of longstanding >> issues faced in SlicerRT [for example, 3] and some issues intrinsic to the >> way the old DICOM tree view was implemented [4]. >> >> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden of >> DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new >> interface to address these issues. Plus Alireza Mehrtash of BWH has added >> a DICOM header browser option to address a longstanding missing feature of >> slicer4 [5]. These have now been integrated into the slicer trunk [6] and >> the new interface is documented on the nightly section of the wiki [7]. >> >> Of course this big of a change may take a little time to settle out, so >> please let us know if you see build or run time issues. Suggestions are >> welcome too. >> >> Cheers from jolly old England, >> Steve >> >> >> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >> >> [2] >> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database_and_Networking >> >> [3] http://na-mic.org/Bug/view.php?id=2828 >> >> [4] http://na-mic.org/Bug/view.php?id=3106 >> >> [5] http://na-mic.org/Bug/view.php?id=1838 >> >> [6] >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22689 >> >> [7] >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/DICOM >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- > +1 919 869 8849 > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Sun Nov 10 14:58:41 2013 From: pieper at ibility.net (Steve Pieper) Date: Sun, 10 Nov 2013 09:58:41 -0500 Subject: [Ctk-developers] [slicer-devel] new dicom interface In-Reply-To: References: Message-ID: Thanks for the feedback! I'm forwarding the thread to the ctk developer list since some ideas relate to the ctk components and some to the slicer integration. I agree with most of the suggestions and I think they will be pretty straightforward to implement (pull requests welcome!). This is sort of a first-pass with the new layout so we can iterate on some of these issues. I didn't want to delay implementing the new table display since it was identified as a critical issue for SlicerRT. -Steve On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov wrote: > I agree configuration is complex and should be in advanced. I was > thinking about list of sources. See attached the way it's done in > syngo.via, would be great to have a similar concept in Slicer, as a > replacement of the directory button. > > I also agree with you completely that the way DICOM database button > functions right now (file dialog popup) is very confusing. > > > On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso wrote: > > The main problem with the directory selector is that the users think > that it is for importing. I've helped several users with this problem, they > all thought that the DICOM import was broken because they used this > database directory selector instead of the Import button. Even after > finding the Import directory they are still confused what this database > directory selection is for and they are not sure if they have to set it to > the directory where they store their DICOM files. We just should not show > this database directory selector on the main GUI. Showing just a listbox > (or checkboxes) with a list of database names (either local filesystem or > remote systems) would be also fine. > > > > In general, _setup_ of DICOM hosts/connections, databases are too > complex operations for most users (IP addresses, port numbers, AE titles, > database directories, ...). However, once they are set up, the > query/retrieve, push, etc. operations are easy to use. So, to reduce > frustration of users and administrators, the GUI for setup should be > clearly separated. GUI for users should be simplified and the GUI for all > DICOM configuration settings should be editable in the Slicer Application > settings. This applies to the Query/Retrieve GUI. The user should only see > a list of data sources and search options; and editing server name, aeitle, > address, port, cget flag, add/remove server, etc. should be only displayed > in the Application settings. > > > > Andras > > > > -----Original Message----- > > From: Andriy Fedorov [mailto:fedorov at bwh.harvard.edu] > > Sent: November 9, 2013 12:23 PM > > To: Andras Lasso > > Cc: pieper at bwh.harvard.edu; slicer-devel at bwh.harvard.edu > > Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface > > > > On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso wrote: > >> ? On a laptop screen only 3-4 patients, studies, and series are > >> visible ? we should see at least about 10 of each. Change the layout > >> (e.g., move the loadables list into a second column; hide the plugin > >> list by default and use a >> button ? similar to the one in the > >> Application settings/Modules ? to show it), decrease the row height of > >> the patients/studies/series tables (it looks to have about 1.5-2x line > >> spacing and/or larger font) > >> > > > > I had a similar concern. Does it make sense to have Patient/Study/Series > panels collapslible? It is currently possible to move the separator all the > way down to use all space for one panel, but it requires a lot of mouse > interaction. > > > > I like the idea of ">>" for plugins list. > > > >> ? Move ?Local database? selector and Make DICOM browser > persistent > >> to an advanced options section (in a popup window or hidden by > >> default) to save space and reduce clutter > >> > > > > Here I would suggest not to hide it, but have a drop-down (ideally -- > > checkable) list of databases. In the future, it would be great to > integrate the remote sources that can be queried into this single drop-down > list to provide a unified experience (this is how syngo.via does it). But > even without remote sources, the use case is often there may be different > databases for different projects, and right now Slicer is not very friendly > in supporting more than one database. > > > > > > > >> > >> > >> Other changes to consider: > >> > >> ? We could remove the ?Close? button (having the ?X? in the > window > >> corner and adding an ?Esc? button shortcut should be enough) > >> > >> ? View header: make it a right-click accessible option on the > >> loadables list (note that currently if no loadable is selected it?s > >> still enabled and shows the latest selected loadable?s info) or a > >> small icon next to the series search bar > >> > >> ? Remove: make it a right-click accessible option (now it?s so > far > >> from all the patient/study/series selector that it?s not very > >> intuitive that it refers to them) or a small trashcan icon next to > >> each search bar > >> > >> > >> > >> Andras > >> > >> > >> > >> From: ctk-developers-bounces at commontk.org > >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper > >> Sent: November 7, 2013 2:49 PM > >> To: slicer-devel at bwh.harvard.edu; ctk-developers at commontk.org > >> Subject: [Ctk-developers] new dicom interface > >> > >> > >> > >> Hello from the CTK hackfest in London! [1] > >> > >> > >> > >> For a while now several of groups have been working on improving the > >> dicom browser in CTK (the one used in the Slicer DICOM module) to make > >> it more consistent with clinical systems and to make it easier to > >> customize. Work really got going at the last hackfest at Queens in > >> Kingston [2] where a design was worked out that would help with a > >> number of longstanding issues faced in SlicerRT [for example, 3] and > >> some issues intrinsic to the way the old DICOM tree view was > implemented [4]. > >> > >> > >> > >> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden > >> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new > >> interface to address these issues. Plus Alireza Mehrtash of BWH has > >> added a DICOM header browser option to address a longstanding missing > >> feature of slicer4 [5]. These have now been integrated into the > >> slicer trunk [6] and the new interface is documented on the nightly > section of the wiki [7]. > >> > >> > >> > >> Of course this big of a change may take a little time to settle out, > >> so please let us know if you see build or run time issues. > >> Suggestions are welcome too. > >> > >> > >> > >> Cheers from jolly old England, > >> > >> Steve > >> > >> > >> > >> > >> > >> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 > >> > >> > >> > >> [2] > >> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database > >> _and_Networking > >> > >> > >> > >> [3] http://na-mic.org/Bug/view.php?id=2828 > >> > >> > >> > >> [4] http://na-mic.org/Bug/view.php?id=3106 > >> > >> > >> > >> [5] http://na-mic.org/Bug/view.php?id=1838 > >> > >> > >> > >> [6] > >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226 > >> 89 > >> > >> [7] > >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D > >> ICOM > >> > >> > >> _______________________________________________ > >> slicer-devel mailing list > >> slicer-devel at bwh.harvard.edu > >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > >> To unsubscribe: send email to > >> slicer-devel-request at massmail.spl.harvard.edu > >> with unsubscribe as the subject > >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel > >> opers/FAQ > >> > >> > >> The information in this e-mail is intended only for the person to whom > >> it is addressed. If you believe this e-mail was sent to you in error > >> and the e-mail contains patient information, please contact the > >> Partners Compliance HelpLine at http://www.partners.org/complianceline > >> . If the e-mail was sent to you in error but does not contain patient > >> information, please contact the sender and properly dispose of the > >> e-mail. > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.pinter at queensu.ca Mon Nov 11 15:55:58 2013 From: csaba.pinter at queensu.ca (Csaba Pinter) Date: Mon, 11 Nov 2013 15:55:58 +0000 Subject: [Ctk-developers] [slicer-devel] new dicom interface In-Reply-To: References: Message-ID: <04C6BCB5F77FFF449DAE728C597984555EDDE8@MP-DUP-MBX-02.AD.QUEENSU.CA> Thank you very much for all the work of developing and integrating the new browser! I remember Andreas showing me a layout switcher feature in the new browser in the spring, which allowed the user to switch from horizontal to vertical view, in which the patient/study/series level are not underneath each other but organized side-by-side. Maybe using the vertical layout would solve the small screen problem. Or at least showing the control if it's still available. csaba From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: November 10, 2013 09:59 To: Andriy Fedorov; ctk-developers at commontk.org Cc: slicer-devel at bwh.harvard.edu Subject: Re: [Ctk-developers] [slicer-devel] new dicom interface Thanks for the feedback! I'm forwarding the thread to the ctk developer list since some ideas relate to the ctk components and some to the slicer integration. I agree with most of the suggestions and I think they will be pretty straightforward to implement (pull requests welcome!). This is sort of a first-pass with the new layout so we can iterate on some of these issues. I didn't want to delay implementing the new table display since it was identified as a critical issue for SlicerRT. -Steve On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov > wrote: I agree configuration is complex and should be in advanced. I was thinking about list of sources. See attached the way it's done in syngo.via, would be great to have a similar concept in Slicer, as a replacement of the directory button. I also agree with you completely that the way DICOM database button functions right now (file dialog popup) is very confusing. On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso > wrote: > The main problem with the directory selector is that the users think that it is for importing. I've helped several users with this problem, they all thought that the DICOM import was broken because they used this database directory selector instead of the Import button. Even after finding the Import directory they are still confused what this database directory selection is for and they are not sure if they have to set it to the directory where they store their DICOM files. We just should not show this database directory selector on the main GUI. Showing just a listbox (or checkboxes) with a list of database names (either local filesystem or remote systems) would be also fine. > > In general, _setup_ of DICOM hosts/connections, databases are too complex operations for most users (IP addresses, port numbers, AE titles, database directories, ...). However, once they are set up, the query/retrieve, push, etc. operations are easy to use. So, to reduce frustration of users and administrators, the GUI for setup should be clearly separated. GUI for users should be simplified and the GUI for all DICOM configuration settings should be editable in the Slicer Application settings. This applies to the Query/Retrieve GUI. The user should only see a list of data sources and search options; and editing server name, aeitle, address, port, cget flag, add/remove server, etc. should be only displayed in the Application settings. > > Andras > > -----Original Message----- > From: Andriy Fedorov [mailto:fedorov at bwh.harvard.edu] > Sent: November 9, 2013 12:23 PM > To: Andras Lasso > Cc: pieper at bwh.harvard.edu; slicer-devel at bwh.harvard.edu > Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface > > On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso > wrote: >> * On a laptop screen only 3-4 patients, studies, and series are >> visible - we should see at least about 10 of each. Change the layout >> (e.g., move the loadables list into a second column; hide the plugin >> list by default and use a >> button - similar to the one in the >> Application settings/Modules - to show it), decrease the row height of >> the patients/studies/series tables (it looks to have about 1.5-2x line >> spacing and/or larger font) >> > > I had a similar concern. Does it make sense to have Patient/Study/Series panels collapslible? It is currently possible to move the separator all the way down to use all space for one panel, but it requires a lot of mouse interaction. > > I like the idea of ">>" for plugins list. > >> * Move "Local database" selector and Make DICOM browser persistent >> to an advanced options section (in a popup window or hidden by >> default) to save space and reduce clutter >> > > Here I would suggest not to hide it, but have a drop-down (ideally -- > checkable) list of databases. In the future, it would be great to integrate the remote sources that can be queried into this single drop-down list to provide a unified experience (this is how syngo.via does it). But even without remote sources, the use case is often there may be different databases for different projects, and right now Slicer is not very friendly in supporting more than one database. > > > >> >> >> Other changes to consider: >> >> * We could remove the "Close" button (having the "X" in the window >> corner and adding an "Esc" button shortcut should be enough) >> >> * View header: make it a right-click accessible option on the >> loadables list (note that currently if no loadable is selected it's >> still enabled and shows the latest selected loadable's info) or a >> small icon next to the series search bar >> >> * Remove: make it a right-click accessible option (now it's so far >> from all the patient/study/series selector that it's not very >> intuitive that it refers to them) or a small trashcan icon next to >> each search bar >> >> >> >> Andras >> >> >> >> From: ctk-developers-bounces at commontk.org >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper >> Sent: November 7, 2013 2:49 PM >> To: slicer-devel at bwh.harvard.edu; ctk-developers at commontk.org >> Subject: [Ctk-developers] new dicom interface >> >> >> >> Hello from the CTK hackfest in London! [1] >> >> >> >> For a while now several of groups have been working on improving the >> dicom browser in CTK (the one used in the Slicer DICOM module) to make >> it more consistent with clinical systems and to make it easier to >> customize. Work really got going at the last hackfest at Queens in >> Kingston [2] where a design was worked out that would help with a >> number of longstanding issues faced in SlicerRT [for example, 3] and >> some issues intrinsic to the way the old DICOM tree view was implemented [4]. >> >> >> >> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden >> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new >> interface to address these issues. Plus Alireza Mehrtash of BWH has >> added a DICOM header browser option to address a longstanding missing >> feature of slicer4 [5]. These have now been integrated into the >> slicer trunk [6] and the new interface is documented on the nightly section of the wiki [7]. >> >> >> >> Of course this big of a change may take a little time to settle out, >> so please let us know if you see build or run time issues. >> Suggestions are welcome too. >> >> >> >> Cheers from jolly old England, >> >> Steve >> >> >> >> >> >> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >> >> >> >> [2] >> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database >> _and_Networking >> >> >> >> [3] http://na-mic.org/Bug/view.php?id=2828 >> >> >> >> [4] http://na-mic.org/Bug/view.php?id=3106 >> >> >> >> [5] http://na-mic.org/Bug/view.php?id=1838 >> >> >> >> [6] >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226 >> 89 >> >> [7] >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D >> ICOM >> >> >> _______________________________________________ >> slicer-devel mailing list >> slicer-devel at bwh.harvard.edu >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >> To unsubscribe: send email to >> slicer-devel-request at massmail.spl.harvard.edu >> with unsubscribe as the subject >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel >> opers/FAQ >> >> >> The information in this e-mail is intended only for the person to whom >> it is addressed. If you believe this e-mail was sent to you in error >> and the e-mail contains patient information, please contact the >> Partners Compliance HelpLine at http://www.partners.org/complianceline >> . If the e-mail was sent to you in error but does not contain patient >> information, please contact the sender and properly dispose of the >> e-mail. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at ibility.net Mon Nov 11 16:08:47 2013 From: pieper at ibility.net (Steve Pieper) Date: Mon, 11 Nov 2013 11:08:47 -0500 Subject: [Ctk-developers] [slicer-devel] new dicom interface In-Reply-To: <04C6BCB5F77FFF449DAE728C597984555EDDE8@MP-DUP-MBX-02.AD.QUEENSU.CA> References: <04C6BCB5F77FFF449DAE728C597984555EDDE8@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: Yes, the feature is still there under the hood but Andreas removed the button to make the interface cleaner. We can add back a preference if we want to allow configuration of this. For now you can experiment on the fly with the line below. I preferred the horizontal layout since it shows more of the columns. But now that we have the building blocks I think we can make whatever interface we want. -Steve >>> slicer.modules.DICOMWidget.detailsPopup.tables.tableOrientation = 1 On Mon, Nov 11, 2013 at 10:55 AM, Csaba Pinter wrote: > Thank you very much for all the work of developing and integrating the > new browser! > > > > I remember Andreas showing me a layout switcher feature in the new browser > in the spring, which allowed the user to switch from horizontal to vertical > view, in which the patient/study/series level are not underneath each other > but organized side-by-side. Maybe using the vertical layout would solve the > small screen problem. Or at least showing the control if it's still > available. > > > > csaba > > > > > > *From:* ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] *On Behalf Of *Steve Pieper > *Sent:* November 10, 2013 09:59 > *To:* Andriy Fedorov; ctk-developers at commontk.org > *Cc:* slicer-devel at bwh.harvard.edu > *Subject:* Re: [Ctk-developers] [slicer-devel] new dicom interface > > > > Thanks for the feedback! I'm forwarding the thread to the ctk developer > list since some ideas relate to the ctk components and some to the slicer > integration. > > > > I agree with most of the suggestions and I think they will be pretty > straightforward to implement (pull requests welcome!). This is sort of a > first-pass with the new layout so we can iterate on some of these issues. > I didn't want to delay implementing the new table display since it was > identified as a critical issue for SlicerRT. > > > > -Steve > > > > On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov > wrote: > > I agree configuration is complex and should be in advanced. I was > thinking about list of sources. See attached the way it's done in > syngo.via, would be great to have a similar concept in Slicer, as a > replacement of the directory button. > > I also agree with you completely that the way DICOM database button > functions right now (file dialog popup) is very confusing. > > > > On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso wrote: > > The main problem with the directory selector is that the users think > that it is for importing. I've helped several users with this problem, they > all thought that the DICOM import was broken because they used this > database directory selector instead of the Import button. Even after > finding the Import directory they are still confused what this database > directory selection is for and they are not sure if they have to set it to > the directory where they store their DICOM files. We just should not show > this database directory selector on the main GUI. Showing just a listbox > (or checkboxes) with a list of database names (either local filesystem or > remote systems) would be also fine. > > > > In general, _setup_ of DICOM hosts/connections, databases are too > complex operations for most users (IP addresses, port numbers, AE titles, > database directories, ...). However, once they are set up, the > query/retrieve, push, etc. operations are easy to use. So, to reduce > frustration of users and administrators, the GUI for setup should be > clearly separated. GUI for users should be simplified and the GUI for all > DICOM configuration settings should be editable in the Slicer Application > settings. This applies to the Query/Retrieve GUI. The user should only see > a list of data sources and search options; and editing server name, aeitle, > address, port, cget flag, add/remove server, etc. should be only displayed > in the Application settings. > > > > Andras > > > > -----Original Message----- > > From: Andriy Fedorov [mailto:fedorov at bwh.harvard.edu] > > Sent: November 9, 2013 12:23 PM > > To: Andras Lasso > > Cc: pieper at bwh.harvard.edu; slicer-devel at bwh.harvard.edu > > Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface > > > > On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso wrote: > >> ? On a laptop screen only 3-4 patients, studies, and series are > >> visible ? we should see at least about 10 of each. Change the layout > >> (e.g., move the loadables list into a second column; hide the plugin > >> list by default and use a >> button ? similar to the one in the > >> Application settings/Modules ? to show it), decrease the row height of > >> the patients/studies/series tables (it looks to have about 1.5-2x line > >> spacing and/or larger font) > >> > > > > I had a similar concern. Does it make sense to have Patient/Study/Series > panels collapslible? It is currently possible to move the separator all the > way down to use all space for one panel, but it requires a lot of mouse > interaction. > > > > I like the idea of ">>" for plugins list. > > > >> ? Move ?Local database? selector and Make DICOM browser > persistent > >> to an advanced options section (in a popup window or hidden by > >> default) to save space and reduce clutter > >> > > > > Here I would suggest not to hide it, but have a drop-down (ideally -- > > checkable) list of databases. In the future, it would be great to > integrate the remote sources that can be queried into this single drop-down > list to provide a unified experience (this is how syngo.via does it). But > even without remote sources, the use case is often there may be different > databases for different projects, and right now Slicer is not very friendly > in supporting more than one database. > > > > > > > >> > >> > >> Other changes to consider: > >> > >> ? We could remove the ?Close? button (having the ?X? in the > window > >> corner and adding an ?Esc? button shortcut should be enough) > >> > >> ? View header: make it a right-click accessible option on the > >> loadables list (note that currently if no loadable is selected it?s > >> still enabled and shows the latest selected loadable?s info) or a > >> small icon next to the series search bar > >> > >> ? Remove: make it a right-click accessible option (now it?s so > far > >> from all the patient/study/series selector that it?s not very > >> intuitive that it refers to them) or a small trashcan icon next to > >> each search bar > >> > >> > >> > >> Andras > >> > >> > >> > >> From: ctk-developers-bounces at commontk.org > >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper > >> Sent: November 7, 2013 2:49 PM > >> To: slicer-devel at bwh.harvard.edu; ctk-developers at commontk.org > >> Subject: [Ctk-developers] new dicom interface > >> > >> > >> > >> Hello from the CTK hackfest in London! [1] > >> > >> > >> > >> For a while now several of groups have been working on improving the > >> dicom browser in CTK (the one used in the Slicer DICOM module) to make > >> it more consistent with clinical systems and to make it easier to > >> customize. Work really got going at the last hackfest at Queens in > >> Kingston [2] where a design was worked out that would help with a > >> number of longstanding issues faced in SlicerRT [for example, 3] and > >> some issues intrinsic to the way the old DICOM tree view was > implemented [4]. > >> > >> > >> > >> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden > >> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new > >> interface to address these issues. Plus Alireza Mehrtash of BWH has > >> added a DICOM header browser option to address a longstanding missing > >> feature of slicer4 [5]. These have now been integrated into the > >> slicer trunk [6] and the new interface is documented on the nightly > section of the wiki [7]. > >> > >> > >> > >> Of course this big of a change may take a little time to settle out, > >> so please let us know if you see build or run time issues. > >> Suggestions are welcome too. > >> > >> > >> > >> Cheers from jolly old England, > >> > >> Steve > >> > >> > >> > >> > >> > >> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 > >> > >> > >> > >> [2] > >> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database > >> _and_Networking > >> > >> > >> > >> [3] http://na-mic.org/Bug/view.php?id=2828 > >> > >> > >> > >> [4] http://na-mic.org/Bug/view.php?id=3106 > >> > >> > >> > >> [5] http://na-mic.org/Bug/view.php?id=1838 > >> > >> > >> > >> [6] > >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226 > >> 89 > >> > >> [7] > >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D > >> ICOM > >> > >> > >> _______________________________________________ > >> slicer-devel mailing list > >> slicer-devel at bwh.harvard.edu > >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > >> To unsubscribe: send email to > >> slicer-devel-request at massmail.spl.harvard.edu > >> with unsubscribe as the subject > >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel > >> opers/FAQ > >> > >> > >> The information in this e-mail is intended only for the person to whom > >> it is addressed. If you believe this e-mail was sent to you in error > >> and the e-mail contains patient information, please contact the > >> Partners Compliance HelpLine at http://www.partners.org/complianceline > >> . If the e-mail was sent to you in error but does not contain patient > >> information, please contact the sender and properly dispose of the > >> e-mail. > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Mon Nov 11 16:11:14 2013 From: lasso at queensu.ca (Andras Lasso) Date: Mon, 11 Nov 2013 16:11:14 +0000 Subject: [Ctk-developers] [slicer-devel] new dicom interface In-Reply-To: References: <04C6BCB5F77FFF449DAE728C597984555EDDE8@MP-DUP-MBX-02.AD.QUEENSU.CA> Message-ID: The vertical layout is good, because we need some width to show all the columns. The problems are that rows very high, thre are unnecessary buttons above/below the widget, and the loadable widget is also below the patient/study/series widget (the loadable widget could be on the right side of the patient/study/series widget instead). Andras From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: November 11, 2013 11:09 AM To: Csaba Pinter Cc: slicer-devel at bwh.harvard.edu; Andriy Fedorov; ctk-developers at commontk.org Subject: Re: [Ctk-developers] [slicer-devel] new dicom interface Yes, the feature is still there under the hood but Andreas removed the button to make the interface cleaner. We can add back a preference if we want to allow configuration of this. For now you can experiment on the fly with the line below. I preferred the horizontal layout since it shows more of the columns. But now that we have the building blocks I think we can make whatever interface we want. -Steve >>> slicer.modules.DICOMWidget.detailsPopup.tables.tableOrientation = 1 On Mon, Nov 11, 2013 at 10:55 AM, Csaba Pinter > wrote: Thank you very much for all the work of developing and integrating the new browser! I remember Andreas showing me a layout switcher feature in the new browser in the spring, which allowed the user to switch from horizontal to vertical view, in which the patient/study/series level are not underneath each other but organized side-by-side. Maybe using the vertical layout would solve the small screen problem. Or at least showing the control if it's still available. csaba From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: November 10, 2013 09:59 To: Andriy Fedorov; ctk-developers at commontk.org Cc: slicer-devel at bwh.harvard.edu Subject: Re: [Ctk-developers] [slicer-devel] new dicom interface Thanks for the feedback! I'm forwarding the thread to the ctk developer list since some ideas relate to the ctk components and some to the slicer integration. I agree with most of the suggestions and I think they will be pretty straightforward to implement (pull requests welcome!). This is sort of a first-pass with the new layout so we can iterate on some of these issues. I didn't want to delay implementing the new table display since it was identified as a critical issue for SlicerRT. -Steve On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov > wrote: I agree configuration is complex and should be in advanced. I was thinking about list of sources. See attached the way it's done in syngo.via, would be great to have a similar concept in Slicer, as a replacement of the directory button. I also agree with you completely that the way DICOM database button functions right now (file dialog popup) is very confusing. On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso > wrote: > The main problem with the directory selector is that the users think that it is for importing. I've helped several users with this problem, they all thought that the DICOM import was broken because they used this database directory selector instead of the Import button. Even after finding the Import directory they are still confused what this database directory selection is for and they are not sure if they have to set it to the directory where they store their DICOM files. We just should not show this database directory selector on the main GUI. Showing just a listbox (or checkboxes) with a list of database names (either local filesystem or remote systems) would be also fine. > > In general, _setup_ of DICOM hosts/connections, databases are too complex operations for most users (IP addresses, port numbers, AE titles, database directories, ...). However, once they are set up, the query/retrieve, push, etc. operations are easy to use. So, to reduce frustration of users and administrators, the GUI for setup should be clearly separated. GUI for users should be simplified and the GUI for all DICOM configuration settings should be editable in the Slicer Application settings. This applies to the Query/Retrieve GUI. The user should only see a list of data sources and search options; and editing server name, aeitle, address, port, cget flag, add/remove server, etc. should be only displayed in the Application settings. > > Andras > > -----Original Message----- > From: Andriy Fedorov [mailto:fedorov at bwh.harvard.edu] > Sent: November 9, 2013 12:23 PM > To: Andras Lasso > Cc: pieper at bwh.harvard.edu; slicer-devel at bwh.harvard.edu > Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface > > On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso > wrote: >> * On a laptop screen only 3-4 patients, studies, and series are >> visible - we should see at least about 10 of each. Change the layout >> (e.g., move the loadables list into a second column; hide the plugin >> list by default and use a >> button - similar to the one in the >> Application settings/Modules - to show it), decrease the row height of >> the patients/studies/series tables (it looks to have about 1.5-2x line >> spacing and/or larger font) >> > > I had a similar concern. Does it make sense to have Patient/Study/Series panels collapslible? It is currently possible to move the separator all the way down to use all space for one panel, but it requires a lot of mouse interaction. > > I like the idea of ">>" for plugins list. > >> * Move "Local database" selector and Make DICOM browser persistent >> to an advanced options section (in a popup window or hidden by >> default) to save space and reduce clutter >> > > Here I would suggest not to hide it, but have a drop-down (ideally -- > checkable) list of databases. In the future, it would be great to integrate the remote sources that can be queried into this single drop-down list to provide a unified experience (this is how syngo.via does it). But even without remote sources, the use case is often there may be different databases for different projects, and right now Slicer is not very friendly in supporting more than one database. > > > >> >> >> Other changes to consider: >> >> * We could remove the "Close" button (having the "X" in the window >> corner and adding an "Esc" button shortcut should be enough) >> >> * View header: make it a right-click accessible option on the >> loadables list (note that currently if no loadable is selected it's >> still enabled and shows the latest selected loadable's info) or a >> small icon next to the series search bar >> >> * Remove: make it a right-click accessible option (now it's so far >> from all the patient/study/series selector that it's not very >> intuitive that it refers to them) or a small trashcan icon next to >> each search bar >> >> >> >> Andras >> >> >> >> From: ctk-developers-bounces at commontk.org >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper >> Sent: November 7, 2013 2:49 PM >> To: slicer-devel at bwh.harvard.edu; ctk-developers at commontk.org >> Subject: [Ctk-developers] new dicom interface >> >> >> >> Hello from the CTK hackfest in London! [1] >> >> >> >> For a while now several of groups have been working on improving the >> dicom browser in CTK (the one used in the Slicer DICOM module) to make >> it more consistent with clinical systems and to make it easier to >> customize. Work really got going at the last hackfest at Queens in >> Kingston [2] where a design was worked out that would help with a >> number of longstanding issues faced in SlicerRT [for example, 3] and >> some issues intrinsic to the way the old DICOM tree view was implemented [4]. >> >> >> >> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden >> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new >> interface to address these issues. Plus Alireza Mehrtash of BWH has >> added a DICOM header browser option to address a longstanding missing >> feature of slicer4 [5]. These have now been integrated into the >> slicer trunk [6] and the new interface is documented on the nightly section of the wiki [7]. >> >> >> >> Of course this big of a change may take a little time to settle out, >> so please let us know if you see build or run time issues. >> Suggestions are welcome too. >> >> >> >> Cheers from jolly old England, >> >> Steve >> >> >> >> >> >> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013 >> >> >> >> [2] >> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database >> _and_Networking >> >> >> >> [3] http://na-mic.org/Bug/view.php?id=2828 >> >> >> >> [4] http://na-mic.org/Bug/view.php?id=3106 >> >> >> >> [5] http://na-mic.org/Bug/view.php?id=1838 >> >> >> >> [6] >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226 >> 89 >> >> [7] >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D >> ICOM >> >> >> _______________________________________________ >> slicer-devel mailing list >> slicer-devel at bwh.harvard.edu >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >> To unsubscribe: send email to >> slicer-devel-request at massmail.spl.harvard.edu >> with unsubscribe as the subject >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel >> opers/FAQ >> >> >> The information in this e-mail is intended only for the person to whom >> it is addressed. If you believe this e-mail was sent to you in error >> and the e-mail contains patient information, please contact the >> Partners Compliance HelpLine at http://www.partners.org/complianceline >> . If the e-mail was sent to you in error but does not contain patient >> information, please contact the sender and properly dispose of the >> e-mail. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From espakm at gmail.com Fri Nov 15 17:28:03 2013 From: espakm at gmail.com (Miklos Espak) Date: Fri, 15 Nov 2013 17:28:03 +0000 Subject: [Ctk-developers] ctkSliderWidget on ctkPopUpWidget: spinbox never gets keyboard focus Message-ID: Hi, I have a drop down control panel with some slider widgets on it. If I click into the spinbox, it should get the keyboard focus and the cursor should start blinking, but it does not. I can select the number by mouse, but cannot type anything into it. If I place the control panel on an ordinary QWidget, all works fine. I added an event filter to the line edit of the spin box to see if it gets the mouse pressed event. It does. But it does not get the FocusIn event. If I put the control panel an a QWidget, then the ctkDoubleSpinBox gets the FocusIn event. Has anybody tried to use a ctkDoubleSpinBox or similar on a ctkPopUpWidget? Any idea, why there the no FocusIn event is not emitted / received if the spinbox is on a popup widget, even if the mouse press event definitely arrives to the line edit? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Fri Nov 15 22:52:22 2013 From: julien.finet at kitware.com (Julien Finet) Date: Fri, 15 Nov 2013 17:52:22 -0500 Subject: [Ctk-developers] ctkSliderWidget on ctkPopUpWidget: spinbox never gets keyboard focus In-Reply-To: References: Message-ID: Hi Miklos, I've noticed that odd behavior but I haven't found the time to investigate much further than what you already did. My gut feeling is that it can't get focus because the popup window is not "active" (only 1 window can be active at a time ?). You might have to play with activateWindow() or something like that. Hth, Julien. On Fri, Nov 15, 2013 at 12:28 PM, Miklos Espak wrote: > Hi, > > I have a drop down control panel with some slider widgets on it. > > If I click into the spinbox, it should get the keyboard focus and the > cursor should start blinking, but it does not. I can select the number by > mouse, but cannot type anything into it. > > If I place the control panel on an ordinary QWidget, all works fine. > > I added an event filter to the line edit of the spin box to see if it gets > the mouse pressed event. It does. But it does not get the FocusIn event. If > I put the control panel an a QWidget, then the ctkDoubleSpinBox gets the > FocusIn event. > > Has anybody tried to use a ctkDoubleSpinBox or similar on a ctkPopUpWidget? > > Any idea, why there the no FocusIn event is not emitted / received if the > spinbox is on a popup widget, even if the mouse press event definitely > arrives to the line edit? > > Cheers, > Miklos > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From espakm at gmail.com Sat Nov 16 11:08:25 2013 From: espakm at gmail.com (Miklos Espak) Date: Sat, 16 Nov 2013 11:08:25 +0000 Subject: [Ctk-developers] ctkSliderWidget on ctkPopUpWidget: spinbox never gets keyboard focus In-Reply-To: References: Message-ID: If I change the window flag from Qt::ToolTip to Qt::PopUp then the widget gets the keyboard focus, but then the panel cannot be pinned. On 15 November 2013 22:52, Julien Finet wrote: > Hi Miklos, > > I've noticed that odd behavior but I haven't found the time to investigate > much further than what you already did. > My gut feeling is that it can't get focus because the popup window is not > "active" (only 1 window can be active at a time ?). > You might have to play with activateWindow() or something like that. > > Hth, > Julien. > > > > On Fri, Nov 15, 2013 at 12:28 PM, Miklos Espak wrote: > >> Hi, >> >> I have a drop down control panel with some slider widgets on it. >> >> If I click into the spinbox, it should get the keyboard focus and the >> cursor should start blinking, but it does not. I can select the number by >> mouse, but cannot type anything into it. >> >> If I place the control panel on an ordinary QWidget, all works fine. >> >> I added an event filter to the line edit of the spin box to see if it >> gets the mouse pressed event. It does. But it does not get the FocusIn >> event. If I put the control panel an a QWidget, then the ctkDoubleSpinBox >> gets the FocusIn event. >> >> Has anybody tried to use a ctkDoubleSpinBox or similar on a >> ctkPopUpWidget? >> >> Any idea, why there the no FocusIn event is not emitted / received if the >> spinbox is on a popup widget, even if the mouse press event definitely >> arrives to the line edit? >> >> Cheers, >> Miklos >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From espakm at gmail.com Sat Nov 16 14:12:09 2013 From: espakm at gmail.com (Miklos Espak) Date: Sat, 16 Nov 2013 14:12:09 +0000 Subject: [Ctk-developers] ctkSliderWidget on ctkPopUpWidget: spinbox never gets keyboard focus In-Reply-To: References: Message-ID: I found a simple solution. Could you please review and merge? https://github.com/commontk/CTK/pull/410 On 16 November 2013 11:08, Miklos Espak wrote: > If I change the window flag from Qt::ToolTip to Qt::PopUp then the widget > gets the keyboard focus, but then the panel cannot be pinned. > > > > On 15 November 2013 22:52, Julien Finet wrote: > >> Hi Miklos, >> >> I've noticed that odd behavior but I haven't found the time to >> investigate much further than what you already did. >> My gut feeling is that it can't get focus because the popup window is not >> "active" (only 1 window can be active at a time ?). >> You might have to play with activateWindow() or something like that. >> >> Hth, >> Julien. >> >> >> >> On Fri, Nov 15, 2013 at 12:28 PM, Miklos Espak wrote: >> >>> Hi, >>> >>> I have a drop down control panel with some slider widgets on it. >>> >>> If I click into the spinbox, it should get the keyboard focus and the >>> cursor should start blinking, but it does not. I can select the number by >>> mouse, but cannot type anything into it. >>> >>> If I place the control panel on an ordinary QWidget, all works fine. >>> >>> I added an event filter to the line edit of the spin box to see if it >>> gets the mouse pressed event. It does. But it does not get the FocusIn >>> event. If I put the control panel an a QWidget, then the ctkDoubleSpinBox >>> gets the FocusIn event. >>> >>> Has anybody tried to use a ctkDoubleSpinBox or similar on a >>> ctkPopUpWidget? >>> >>> Any idea, why there the no FocusIn event is not emitted / received if >>> the spinbox is on a popup widget, even if the mouse press event definitely >>> arrives to the line edit? >>> >>> Cheers, >>> Miklos >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Sun Nov 17 18:55:06 2013 From: julien.finet at kitware.com (Julien Finet) Date: Sun, 17 Nov 2013 11:55:06 -0700 Subject: [Ctk-developers] ctkSliderWidget on ctkPopUpWidget: spinbox never gets keyboard focus In-Reply-To: References: Message-ID: Hi Miklos, This is great news ! The patch looks good to me. Did you try it on windows, linux and mac ? Before merging, let's make sure Slicer still works with that change. I'm on vacation this week so it will be a challenge for me to run those tests, Jc, do you have time to try it ? Julien. On Sat, Nov 16, 2013 at 7:12 AM, Miklos Espak wrote: > I found a simple solution. Could you please review and merge? > > https://github.com/commontk/CTK/pull/410 > > > > On 16 November 2013 11:08, Miklos Espak wrote: > >> If I change the window flag from Qt::ToolTip to Qt::PopUp then the widget >> gets the keyboard focus, but then the panel cannot be pinned. >> >> >> >> On 15 November 2013 22:52, Julien Finet wrote: >> >>> Hi Miklos, >>> >>> I've noticed that odd behavior but I haven't found the time to >>> investigate much further than what you already did. >>> My gut feeling is that it can't get focus because the popup window is >>> not "active" (only 1 window can be active at a time ?). >>> You might have to play with activateWindow() or something like that. >>> >>> Hth, >>> Julien. >>> >>> >>> >>> On Fri, Nov 15, 2013 at 12:28 PM, Miklos Espak wrote: >>> >>>> Hi, >>>> >>>> I have a drop down control panel with some slider widgets on it. >>>> >>>> If I click into the spinbox, it should get the keyboard focus and the >>>> cursor should start blinking, but it does not. I can select the number by >>>> mouse, but cannot type anything into it. >>>> >>>> If I place the control panel on an ordinary QWidget, all works fine. >>>> >>>> I added an event filter to the line edit of the spin box to see if it >>>> gets the mouse pressed event. It does. But it does not get the FocusIn >>>> event. If I put the control panel an a QWidget, then the ctkDoubleSpinBox >>>> gets the FocusIn event. >>>> >>>> Has anybody tried to use a ctkDoubleSpinBox or similar on a >>>> ctkPopUpWidget? >>>> >>>> Any idea, why there the no FocusIn event is not emitted / received if >>>> the spinbox is on a popup widget, even if the mouse press event definitely >>>> arrives to the line edit? >>>> >>>> Cheers, >>>> Miklos >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Nov 18 19:55:37 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 18 Nov 2013 14:55:37 -0500 Subject: [Ctk-developers] ctkSliderWidget on ctkPopUpWidget: spinbox never gets keyboard focus In-Reply-To: References: Message-ID: Hi Miklos, Thanks for your contribution. Just tried your changes and it also fixes the problem within Slicer. Would be awesome to integrate it. If possible, could you consider adding a more descriptive commit message explaining which problem the commit is fixing. Referencing the issue using something like "See #409" would also be great. Thanks Jc On Sun, Nov 17, 2013 at 1:55 PM, Julien Finet wrote: > Hi Miklos, > > This is great news ! > The patch looks good to me. Did you try it on windows, linux and mac ? > > Before merging, let's make sure Slicer still works with that change. > I'm on vacation this week so it will be a challenge for me to run those > tests, Jc, do you have time to try it ? > > Julien. > > > > On Sat, Nov 16, 2013 at 7:12 AM, Miklos Espak wrote: > >> I found a simple solution. Could you please review and merge? >> >> https://github.com/commontk/CTK/pull/410 >> >> >> >> On 16 November 2013 11:08, Miklos Espak wrote: >> >>> If I change the window flag from Qt::ToolTip to Qt::PopUp then the >>> widget gets the keyboard focus, but then the panel cannot be pinned. >>> >>> >>> >>> On 15 November 2013 22:52, Julien Finet wrote: >>> >>>> Hi Miklos, >>>> >>>> I've noticed that odd behavior but I haven't found the time to >>>> investigate much further than what you already did. >>>> My gut feeling is that it can't get focus because the popup window is >>>> not "active" (only 1 window can be active at a time ?). >>>> You might have to play with activateWindow() or something like that. >>>> >>>> Hth, >>>> Julien. >>>> >>>> >>>> >>>> On Fri, Nov 15, 2013 at 12:28 PM, Miklos Espak wrote: >>>> >>>>> Hi, >>>>> >>>>> I have a drop down control panel with some slider widgets on it. >>>>> >>>>> If I click into the spinbox, it should get the keyboard focus and the >>>>> cursor should start blinking, but it does not. I can select the number by >>>>> mouse, but cannot type anything into it. >>>>> >>>>> If I place the control panel on an ordinary QWidget, all works fine. >>>>> >>>>> I added an event filter to the line edit of the spin box to see if it >>>>> gets the mouse pressed event. It does. But it does not get the FocusIn >>>>> event. If I put the control panel an a QWidget, then the ctkDoubleSpinBox >>>>> gets the FocusIn event. >>>>> >>>>> Has anybody tried to use a ctkDoubleSpinBox or similar on a >>>>> ctkPopUpWidget? >>>>> >>>>> Any idea, why there the no FocusIn event is not emitted / received if >>>>> the spinbox is on a popup widget, even if the mouse press event definitely >>>>> arrives to the line edit? >>>>> >>>>> Cheers, >>>>> Miklos >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> >>>> >>> >> > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Wed Nov 20 23:31:03 2013 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 20 Nov 2013 18:31:03 -0500 Subject: [Ctk-developers] Introducing CTK_USE_SYSTEM_* option and a simpler external project description Message-ID: Hi Folks, While working on the packaging of CTK for debian, we needed to be able to easily tell the build system which dependency should be expected on the system and which one should be externally build. I propose to integrate a pull requests that will make usage of such option possible: https://github.com/jcfr/CTK/compare/418-support-use-system-option https://github.com/jcfr/ExternalProjectsContrib/compare/418-support-use-system-option ... and will also simplify the management of external projects. Indeed, the CTK external project are now more similar to the one used in Slicer, they both used a macro named "(ctk|slicer)CheckExternalProjectDependencies" that prints a neat informative text allowing to understand the state of an external project: [...] -- Generating done -- Build files have been written to: /home/jchris/Projects/CTK-Debug/ExternalProjectsContrib-proj [...] [100%] Built target ExternalProjectsContrib -- SuperBuild - First pass -- SuperBuild - First pass - done -- SuperBuild - Log4Qt[OPTIONAL] -- SuperBuild - ZMQ[OPTIONAL] -- SuperBuild - OpenIGTLink[OPTIONAL] -- SuperBuild - XIP[OPTIONAL] -- SuperBuild - ITK[OPTIONAL] -- SuperBuild - CTK => Requires VTK, PythonQt, DCMTK, QtSOAP, qxmlrpc, CTKData, QuaZip, qRestAPI, -- SuperBuild - VTK[OK] -- SuperBuild - PythonQt[OK] -- SuperBuild - DCMTK[OK] (SYSTEM) [...] -- SuperBuild - QtSOAP[OK] -- SuperBuild - qxmlrpc[OK] -- SuperBuild - CTKData[OK] -- SuperBuild - QuaZip[OK] -- SuperBuild - qRestAPI[OK] -- SuperBuild - CTK[OK] -- Configuring done -- Generating done -- Build files have been written to: /home/jchris/Projects/CTK-Debug In case you have some external project files living in your fork of ExternalProjectsContrib, I wrote a small migration guide to help you transition. See http://www.commontk.org/index.php/Documentation/MigrationGuide/ExternalProject#Transitioning_to_ExternalProject_following_0c423189d Short term, the plan is to integrate these topics in the coming days. Ultimately, the idea would be to have a very convenient set of CMake allowing to very simply manage "complex" external project based system. These files would leave in dedicated github repository that could easily be integrated in any project with the help of a "git subtree" command. Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: