[Ctk-developers] CTK Update to latest DCMTK

[Jean-Christophe Fillion-Robin]

Regarding MT and /MTd, would it make sens to have a CMake option named
DCMTK_MULTITHREADED ?

See also inline comments.

On Mon, Aug 1, 2011 at 11:45 AM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi JC,
>
> Am 01.08.2011 16:35, schrieb Jean-Christophe Fillion-Robin:
>
>
>  Nevertheless, it seems CTK build is now broken :(
>>
>
> Yes, and totally my fault ;)


No prob :) Seems we identify and are on the good track to get the problem
fixed.


>
>
>  Few remarks:
>>
>> 1) In CMakeExternals/DCMTK.cmake - Instead of specifying
>> "origin/master", would it be possible to use a specific SHA1 as a
>> GIT_TAG. Doing so will be more deterministic and ensure all developers /
>> checkout will behave the same way. Before, origin/patched associated with
>> our own DCMTK was a "controller" moving target."
>>
>
> I think this is a good idea. Let's adapt the remaining issues to be fine on
> the current DCMTK HEAD commit and take that one. I really do not recommend
> taking 3.6.0 since I added C-MOVE code (needed for receiving images) to the
> DcmSCU class afterwards.


Make sens - It just a matter of specifying the SHA1 to be the latest head
known to compile.


>
>
>  2) DCMTK build is broken - How should we address the problem:
>>
>
> DCMTK itself is broken? There is a warning about mktemp, I guess that is
> easy to fix and I will do it hopefully already today. Are there any other
> issues, just let me know and I'll fix it in DCMTK.


DCMTK build by CTK is/was broken. The flag fPIC was not added automatically
...


>
>
>  * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
>> on github so that we can fork and easily contribute patches ? * Mirror
>> DCMTK ourself on commontk/dcmtk
>>
>
> I would not be happy about any of these. Let's get things running on all
> platforms now; I will do my part as good as possible and with priority.
> Then
> we can take a fixed commit and update that from time to time in CTK. We can
> do that regulary, as you like, or as I can give you a hint if interesting
> features (for CTK) come in.


I guess submitting patch to Offis directly seems to be the way to go. We
could also publish our topic branch on commontk/DCMTK to that you can review
them before final integration upstream.


>
>
>> Assigned issue https://github.com/commontk/**CTK/issues/22<https://github.com/commontk/CTK/issues/22>to Michael
>>
>> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC
>> is passed.
>>
>
> Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
> anyway sooner or later, so we should also take it over. I would just take
> over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.


Very true - i didn't know how responsive you would be. Do you know when
things will be fixed?


>
>
>> 3) Should we move to a master/next workflow ?
>>
>> Having a continuous dashboard setup for both master and next, we will be
>> able to easily identify issue and ensure that our change compile properly
>> on all targets platform.
>>
>
> Given my beginner's status in git and somehow also CTK, I would totally
> welcome that! So plus 1 from my side ...


Extra - Any other thoughts from the CTK community ?


>
>
> Best regards,
> Michael
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/c82bc4ab/attachment.htm>