Itk: Custom module's export generated in wrong folder.

[al-sabr]

Ok the module is now recognized but somehow it doesn't generate the export file which is itkInternalExport.h

How ís it possible to make my module generate its own Export file? Do I need to specify it somewhere?

Ohh that's weird the file is generated but in the wrong folder

It should actually be in Modules/Basic/Internal/itkInternalExport.h

Why does it find itself in Common when I deactivated the Group_Common?

[al-sabr]

Also how does the itkExport.h gets generated because I have also a compilation error telling me that the file is non-existent.

[al-sabr]

It seems that this is the reason why the file gets generated in the wrong folder:

https://github.com/InsightSoftwareConsortium/ITK/blob/c2116d956b17288dfd3bd58aec2fb4cade4324b1/CMake/ITKModuleMacros.cmake#L220

How to handle this ? Can this be a solution? al-sabr@9f48f81

I tried it and it doesn't change anything.

[dzenanz]

ITKCommon is assumed to always be built. Your rewrite violates that assumption.

[al-sabr]

ITKCommon is not compiling because of previous GDSM problem. That's why I have to do this so that it doesn't depend on that whole Common thing. Also it means that the modular granularity is problematic.

Actually Common should not be that dependent to so many other modules and better isolated to be able to compile on its own with less compile breaking dependencies.

Other modules should link to something more Basic than Common IMHB. All of this to be able to use Blueberry is really showing how the architect for that code didn't went beyond their own needs.

Even with this hack it doesn't work ... al-sabr@90f23d5

The file is still owned by ITKCommon which shows that this not a good approach forcing ITKCommon if we don't want.

This thread explains what I am trying to say : https://www.piceasmart.com/2019/10/granularity-and-modularity-in-content-design/

[al-sabr]

This is the error I am talking about... ITKCommon doesn't compile : https://github.com/commontk/CTK/issues/949#issuecomment-777070686

Why doesn't https://github.com/InsightSoftwareConsortium/ITK/blob/c2116d956b17288dfd3bd58aec2fb4cade4324b1/CMake/ITKModuleMacros.cmake#L222 work if I unset that variable?

Also I don't understand where itkExport.h is created.

Can you help to identify how itkExport.h is generated?

[jhlegarreta]

@al-sabr I've been loosely following the threads you posted across many channels, including issues such as this one, posts to the ITK discourse, CTK issues in GitHub or the CMake discourse, and I think a comment is necessary as a maintainer of the toolkit/long time contributor.

Although I do not have the resources to have a look into the issues, a few general comments apply to the use of the channels and resources:

• Posting the same issue (or its variants) across multiple channels makes more difficult to keep track of it. This applies both to maintainers that might take the time to have a look into the issue, and to other members that might eventually bump into the same problem and be willing to follow the discussion and hints provided.
• ITK's GitHub issues are not intended to ask questions. Questions should be posted in ITK's discourse.
• ITK's GitHub issues have many templates to facilitate building an accurate and detailed report that might allow other individuals reproduce your results or failures. Failing to provide such information limits the insight you may get. And in either case, note that maintainers might not be in a position to reproduce the issue for various reasons.
• You can set up regular builds for your application and have them submitted to a CDash server so that the failure reports are visible and can be inspected.
• Bug fixes and enhancements are much appreciated and everybody is welcome to submit them.

As for ITK's design,

• Note that ITK is being developed since 1999, it has enabled and enables many cutting edge applications across a variety of scientific fields, supports reproducible open scientific research, and is a model as a long lasting community effort in such a context.
• A large number of people have contributed and put their valuable time and efforts into ITK. Many of these individuals are prominent researchers and developers, have a vast experience across various domains, and their design decisions have been grounded on the basis of evidence, reproducibility, knowledge sharing, and overall excellent software development practice.
• Note that a number of large scale and third-party software, both private and public, depend on ITK, and maintain regular (i.e. daily) testing that proves that ITK works as expected under various conditions.

And especially, and more generally,

• ITK has a code of conduct and its discourse guidelines are a necessary read before participating in community discussions.
• Some comments that were made in the context of such posts and their tone are largely unwelcome within this community.
• Many contributors contribute to ITK as a side project on their own time. Their time is valuable, as valuable as one's own time. So be considerate, and think about it when posting failure reports and messages.

So, please keep the discussion civilized and acknowledge the effort of the many individuals that have provided support.

[al-sabr]

Let me know if I said something which was out of order. I'll try to be more civilized.

[dzenanz]

You are combining libraries in ways not envisioned by their authors, but you are expecting help as if you are using it in a supported way. You want to create a new library by forking CTK? Go ahead, but don't blame ITK that a mutilated version of it is not compiling.

[al-sabr]

I thought that ITK is modular and tried to move some stuff out to bypass the compilation error generated by GDSM. I envisioned that it will be easy since there is the documentation but I keep hitting road blocks. And no one explained why GDSM is not compiling even though I went the way you suggested @dzenanz. At some point I might be headed wrong but I definitely appreciate your input since you are there from the beginning.

I didn't mean bad by saying that the old code is still built like a monolith because at that time (1999) OSGi began and it was in its earlier age. Also taking a monolith and then making it fully modular is not an easy task.

I just realized that I might help with adding more granularity into the Common by moving something in another group like Basic or Foundation.

[jhlegarreta]

Let me know if I said something which was out of order. I'll try to be more civilized.

No need to quote what has been said: the messages and their history is accessible.

Just bear the above comments in mind to keep ITK's communication and contribution channels being a healthy environment.

[al-sabr]

@dzenanz I added an optional parameter for the itk_module_impl with the BYPASS_OWNERSHIP flag

al-sabr/ITK@d164c87

So the file generated will not end up in the Common folder

al-sabr/ITK@46da573

al-sabr/ITK@3819bc5

Does this make sense ? Bear in mind that I am really new to CMake and I am trying to find my way out somehow. I thought that an optional parameter will not break anything but I really don't know.

Also I don't understand where itkExport.h is created.

Can someone help me to identify how itkExport.h is generated?

I just tested this modification and the ITKInternalExport.h gets generated in the correct folder which is Modules/Basic/Internal/include/ITKInternalExport.h

What I want to know is : does my modification going to affect the rest of ITK?

[al-sabr]

@jhlegarreta I will try my best to keep it cool and healthy thanx for your guidance.

[al-sabr]

@dzenanz My modifications are working perfectly!!!!! Yay

Also CTK is compiling mbilog & mitk & Blueberry with my modified version of ITK with the new module.

[dzenanz]

Maybe now provide closure and point to your solution on all the opened (some of which are now closed) issues and forum posts? For bonus points, explain what the problem was, what you tried, why it didn't work and what finally worked. Maybe write this longer explanation in once place and link to it from other discussions.

[al-sabr]

I will try to do a detailed explanation of an overview of what we went through just to extract from MITK the mbilog component & Blueberry Framework and to port it for CTK so that we become totally independant of ITK & VTK & all other unnecessary dependencies from CTK concerning Medical Visualization Components. I was not successful in getting rid of ITK but it is used to its strict minimum. I will write more about it tomorrow.

[al-sabr]

For this ticket the solutions were:

al-sabr/ITK@46da573

al-sabr/ITK@4e31676

al-sabr/ITK@ef4785f

Because all the ${itk-module}Exports.h were all ending up in the Modules/Core/Common/

I just added a non-breaking optional parameter to by pass the ownership to the independant Module or Group of module's Export file instead of Core/Common. I needed this approach because I wanted skip the GDCM compilation error I had earlier when I tried your suggestion in another thread. The only thing I was depending on for Blueberry, mbilog & mitk module in CTK was KWSys & VXL from ITK. Since Core/Common was the main center point I had to extract from Core/Common and few files that I needed to be able to compile ITK with more granularity than what is offered right now in Core/Common.

That's why I create another group called Basic with a module named Internal with only KWSys & VXL.

To be able to compile ITK with only this Basic/Internal module I had to deactivate the default module compilation + turn Core/Common module OFF and turn Basic/Internal ON.

Everyone can follow the trials and tribulations on the repo : https://github.com/al-sabr/ITK/commits/itk-basic-internal-kws-vxl

This is the compiling custom CTK which incorporates mbilog, mitk & Blueberry Framework : https://github.com/al-sabr/CTK/commits/ctk-blueberry-port-from-mitk

[al-sabr]

Is my previous post clear enough for this ticket ?

[dzenanz]

Good explanation for this ticket.