Plans for a new release?

[yurivict]

The last release was in 2018. There were many commits since.

[jamesobutler]

Currently there is no difference between what would be a tagged release versus a regular commit along the CTK development line. There isn’t one stable commit over another as #839 was probably hoping there would be.

CTK is used as a remote toolkit primarily in the context of supporting 3D Slicer which does have tagged stable releases. Slicer specifies a commit hash of CTK to use.

Are you using CTK in the context of 3D Slicer? Is there another reason why you may be requesting a tagged release and not using a specific commit hash like 3D Slicer?

[yurivict]

3D Slicer's CMakeLists only uses find_package(CTK) here.

The reason I asked is that we have the FreeBSD port for CMT which is never updated because there are no new tags in the repository.

[jamesobutler]

Slicer is typically built with a superbuild project that pulls and builds CTK based on a commit hash of CTK rather than reusing from a CTK source on system. This is because Slicer frequently updates CTK to a new commit hash rather than generating a CTK tagged release.

I’m not sure how helpful tagging a specific CTK release will be considering it would only be compatible with very specific and likely non-stable version of Slicer. Do you know of CTK used elsewhere?

[yurivict]

I don't know other users.

[jamesobutler]

Did you get Slicer building with your FreeBSD ports as you were mentioning a few years ago in https://discourse.slicer.org/t/is-vtkguisupportqtopengl-available-in-8-2-0-with-vtk-rendering-backend-opengl2/4854/5?u=jamesobutler? CTK/VTK/ITK are used to build Slicer and we’ve updated major versions of VTK and ITK since that post.

[lassoan]

MITK is one other large open-source project that relies on CTK. I heard about a number of closed-source projects using CTK (mainly the DICOM browser feature). They are all fine with using specific hashes on the main branch, but we can add a tag time to time if there is a specific need for it.

[yurivict]

Many port/package systems have new version auto-discovery mechanism that notifies maintainers, and without new tags these ports remain un-updated.

[yurivict]

Currently 3DSlicer isn't compatible with CTK.
3DSlicer expects /usr/local/lib/ctk-0.1/CMake/ctkFunctionGeneratePluginUseFile.cmake which current CTK doesn't install:

CMake Error at /usr/local/lib/ctk-0.1/CMake/CTKConfig.cmake:86 (include):
  include could not find requested file:

    /usr/local/lib/ctk-0.1/CMake/ctkFunctionGeneratePluginUseFile.cmake
Call Stack (most recent call first):
  CMakeLists.txt:846 (find_package)


CMake Error at /usr/local/lib/ctk-0.1/CMake/CTKConfig.cmake:90 (include):
  include could not find requested file:

    /usr/local/lib/ctk-0.1/CMake/ctkFunctionExtractPluginTargets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:846 (find_package)

[lassoan]

Currently 3DSlicer isn't compatible with CTK

3D Slicer uses latest CTK master. There are no build errors on any platforms: https://slicer.cdash.org/index.php?project=SlicerPreview

[pieper]

It can't hurt to make a tag, although it is more maintenance burden for us. Maybe tag the commit the one we used for Slicer 5. and we can make 5.2 when Slicer 5.2 is released.

Just so you understand where we are coming from @yurivict Slicer has a number of dependencies that we sometimes need to patch so we have found it hard in the past to support the libs that come with any particular OS (it's been tried in the past with debian and we finally gave up). That's why Slicer is distributed with it's own whole ecosystem of libs (python, vtk, qt, etc) so it doesn't get broken by an OS update. I'm sure that sounds like bloat from an os perpective but it's the best use of our resources.

It would be great to see slicer's build system ported to freebsd but I don't know that anyone has experience with that.

[yurivict]

Maybe tag the commit the one we used for Slicer 5. and we can make 5.2 when Slicer 5.2 is released.

This would make matching the releases of Slicer and CTK easier.

[yurivict]

That's why Slicer is distributed with it's own whole ecosystem of libs (python, vtk, qt, etc) ...

Ideally there should be a variable for each such dependency, for example USE_EXTERNAL_VTK for systems which have clean and up-to-date ports systems, like FreeBSD.

Bundling dependencies isn't sustainable. Also package builders don't allow downloads during build for security reasons.

[jamesobutler]

@yurivict Do you have plans to update the ITK version? I see the ports is specifying ITK 5.0.1 https://github.com/freebsd/freebsd-ports/blob/main/science/InsightToolkit/Makefile while Slicer uses a version based on ITK 5.3rc04. Are you maintaining the latest versions of things in FreeBSD-ports and making sure things are compatible with other packages? Slicer developers don’t have the funding/resources to maintain this when the majority of the Slicer community does not use FreeBSD.

[pieper]

Ideally there should be a variable for each such dependency, for example USE_EXTERNAL_VTK for systems which have clean and up-to-date ports systems, like FreeBSD.

Yes, it's possible to use the system libraries for all our dependencies (USE_SYSTEM_) but in practice, as James points out with the ITK example, even the most diligent package maintainers never seem to have the versions we need.

Bundling dependencies isn't sustainable.

That's what I suspected you would think, but the fact is it's worked for us for 20 years. : )

[yurivict]

All ports in the FreeBSD tree are compatible. There could be some run-time issues since maintainers don't necessarily test things exhaustively. But everything at least builds.

I'll look into updating ITK.

---

That's what I suspected you would think, but the fact is it's worked for us for 20 years. : )

According to Repology only Arch Linux has a port for 3DSlicer, which is a binary port. Others have policy against binary packages for security reasons, and they aren't able to build it from source. So your users don't have a benefit of installing your software in a normal, comfortable way, and have to do it manually.

[pieper]

Yes, it is a burden for us and our users to have the current system and I would like if if there were a cleaner way to distribute software across platforms. But realistically most big applications work the same way Slicer does where you get a package for your OS and it comes with what you need. Realistically we need to keep all our versions in sync (linux, mac, and windows) because otherwise support would be impossible. It would be great to add FreeBSD to that list so that users could benefit from an up to date application version that works the same the version other uses have. We require a community built around our software than around the OS they choose to use for everything else.

But if Arch Linux can be up to date with our current release, then it should be possible for other distributions to do so as well, it just takes dedicated effort.

[lassoan]

@yurivict This is becoming an interesting conversation. I did not see the rationale behind your question, but I understand it much better now.

For me the main question is how multiple applications could all use the same system libraries? For example, VTK, ITK, CTK, DCMTK, etc. libraries are continuously developed, and each application that use them needs very specific version of each library, built with a very specific set of options. So, even if Slicer application used the same VTK version as MITK application, their VTK would be still incompatible because they were built with different options. How/where could this be addressed?

[yurivict]

So, even if Slicer application used the same VTK version as MITK application, their VTK would be still incompatible because they were built with different options. How/where could this be addressed?

What are the examples of incompatible options in VTK? Last time I looked was yesterday, and VTK build options are incremental. They have a lot of optional modules that are or aren't built. There is also an option that enables all modules. With all modules enabled VTK should be compatible with all users, no?

[lassoan]

Yes, many options are kind of incremental, but still there are a lot of incompatible options. Some examples:

• VTK_USE_CUDA
• VTK_GROUP_ENABLE_Qt (and which Qt version? there is not one common Qt version that works for all VTK-based applicartions)
• VTK_ENABLE_REMOTE_MODULES (and if enabled, which remote modules are enabled)
• VTK_SMP_IMPLEMENTATION_TYPE (some projects use OpenMP, some TBB)
• VTK_ENABLE_KITS
• VTK_ENABLE_LOGGING
• VTK_LEGACY_REMOVE
• VTK_TARGET_SPECIFIC_COMPONENTS
• CMAKE_CXX_STANDARD_REQUIRED

Some choices are more common than others, but there are so many of these options that even if we use the most common choices, overall this common VTK build would be unusable for almost all VTK-based applications. Probably it could be possible to share some parts VTK between applications if VTK was split up to smaller, more independent libraries. Splitting up could be useful for some other reasons, too, but it would require significant effort and may mean increased development and maintenance workload, so it would be unlikely to happen in the foreseeable future.

[yurivict]

Some listed above options are also incremental: VTK_ENABLE_REMOTE_MODULES adds remote modules, VTK_LEGACY_REMOVE removes legacy APIs,

Some other listed options (VTK_ENABLE_LOGGING, CMAKE_CXX_STANDARD_REQUIRED) are just build options adding logging/changing CXX standard. They are kind of orthogonal and user projects would work fine regardless of their values.

And VTK_SMP_IMPLEMENTATION_TYPE, VTK_GROUP_ENABLE_Qt should be matched between the user projects/VTK.

These types of potential incompatibilities and matched options happen for many projects, but they still work without bundling libraries.

[jamesobutler]

They might still work, but they won't be using the same configuration as another 3D Slicer user on a different platform. For debugging issues we prioritize that the same configuration is used cross-platform, not slight variations where some use C++14 and others use C++17 as the standard or some use option A and others option B. This will continue the Linux "use at your own risk" because the unique configuration of options is not going to be tested or recommended compared to the defined specific configuration of a tagged 3D Slicer release for cross-platform use.

[jamesobutler]

Xref the Slicer issue Slicer/Slicer#5271 that is on this topic of using regular system packages rather than downloaded versions during the build process.

[RafaelPalomar]

I would totally support systematic versioning and releases for CTK. It would be a great help for the Systole project (https://github.com/SystoleOS/gentoo-overlay) as packaging of 3D Slicer dependencies is one of the main features.

[jcfr]

A released was created on 2023.07.13.
See https://github.com/commontk/CTK/releases/tag/2023.07.13

Corresponding issue was the :

• Create 2023.07 release #1104

Moving forward, we will plan on releasing CTK on a quarterly basis prior releasing Slicer.

[jcfr]

Closing. Creation of an issue template with the steps for releasing CTK will be added shortly:

• Add issue template for creating CTK release #1173