Build with ITK - install package about rtk

[LucasGandel]

Indeed... I broke compilation within ITK while trying to fix the install step in the latest commit. I'm currently working on a fix.
In the meantime you should be able to bypass the issue if you use the "NO_INSTALL" parameter as it was done here.

[dkuegler]

This error is in the configure step of cmake

[SimonRit]

RTK has moved to being an external module of ITK, maybe one cannot compile from an installed ITK. What do you think @LucasGandel?

[LucasGandel]

Exactly, even if you could provide the ITKModuleExternal.cmake script from the sources, you would hit the following error message :

CMake/ITKModuleExternal.cmake:11:
message(FATAL_ERROR
"Modules can only be built against an ITK build tree; they cannot be built against an ITK install tree.")

[SimonRit]

Thanks for the confirmation. I guess we need to clarify this in RTK's documentation. We are preparing a release for the coming days to be able to submit a file to ITK for compilation of RTK from within ITK as a remote module. For now, if you just clone RTK in ITK_SRC/Modules/Remote or in ITK_SRC/Modules/External, you will get a Module_RTK option that you can activate to compile RTK.
I'll leave this issue open until we have changed the error message for something more meaningful than what you currently have.

[dkuegler]

This should really be a new issue, but since it is easier to explain:
I moved RTK to Modules/External and activated Module_RTK.
On Windows, when compiling ITK_CudaComman as BUILD_SHARED, I get:
C2941: definition of dllimport static data member not allowed in itkCudaContextManager.cxx
This is because ITK_CudaCommon is not defined, since the target in not defined as a shared library and therefore in the itkCudaWin32Header.h, the library is defined as __declspec(dllimport) which is bogus.

Solution: in utilities/ITKCudaCommon/CMakeLists.txt:11
add_library(ITKCudaCommon ${ITK_LIBRARY_BUILD_TYPE} ${ITKCudaCommon_SRC})

If itkcudacommon should always be static, then the declspec declarations should be removed....

[dkuegler]

Also, I think the whole install infrastructure is sadly not properly set up.
I guess that is still one of the todos?

[SimonRit]

Thanks for your efforts and your patience.
On the first point, the weird part is that I successfully compile RTK nightly on Windows with shared and static libraries, see the dashboard. I don't know why you're encountering problems I don't have. Moreover, I never see such a ${ITK_LIBRARY_BUILD_TYPE} in ITK code. Any suggestion? I'm really lost with this Windows stuff.

On the install infrastructure, I guess you have understood I'm really not skilled on this part. So yes, it's a todo but I'm not sure what is to be done. What need to be installed are includes, libraries, exe and cmake scripts. Any suggestions on how to proceed is welcome.

[agravgaard]

I think the following error is related to this issue:
I'm now getting CMake Error: install(EXPORT "ITKTargets" ...) includes target "RTK" which requires target "lpsolve55" that is not in the export set. when configuring ITK with RTK as a external module, during the generation step of CMake.

Docker file, for building ITK/RTK

[LucasGandel]

Building within ITK with static/shared libraries should be OK now that #209 is integrated.
You might want to give a try to latest master.

[agravgaard]

Thanks! 👍
It seems to work well, now it's only my own code causing my CI to fail...

[LucasGandel]

#210 adds an explicit check to prevent building against an ITK install tree.
#209 should have fixed the shared libraries issue when building within ITK.
@dkuegler Is there anything else or can we safely close this issue?

[SimonRit]

@LucasGandel I have setup a first nightly build with static / release / FFTW and it fails. It seems that a27a558 is not a good solution for this build. Are you sure it's necessary for shared libraries?

[LucasGandel]

@SimonRit Did you use a remote file? It seems that a27a558 was required when building as an external module, but not when building as a remote. It does not really makes sense to me right now, I'll investigate.

[SimonRit]

Yes, here is RTK.remote.cmake:

itk_fetch_module(RTK
"Reconstruction Toolkit (RTK) http://www.openrtk.org/"
GIT_REPOSITORY ${git_protocol}://github.com/SimonRit/RTK.git
GIT_TAG master
)

[agravgaard]

I didn't need the RTK_BUILD_APPLICATIONS flag, so I didn't look so deep into it, but shouldn't it be enough with an if(NOT ITK_SOURCE_DIR) around find_package ?

[SimonRit]

That's what used to be there and @LucasGandel removed is for shared libs I believe.

[LucasGandel]

I removed it a few month ago when trying to build as a remote. I guess things have changed on the itk side and this should be added back.
@SimonRit Can you please make the change or do you want me to do it?

[SimonRit]

As far as I know, this issue is now fixed in the new release. Re-open it if required.

[SimonRit]

I don't know. Can you open a separate issue and detail your configuration?
Thanks,
Simon

[Quinlly]

OK，I have resolved the problem by replacing RTK-2.0.0 with RTK-1.4.0. [email protected] From: Simon Rit Date: 2019-07-15 17:25 To: SimonRit/RTK CC: Lizhong Qiu; Comment Subject: Re: [SimonRit/RTK] Build with ITK - install package (#207) I don't know. Can you open a separate issue and detail your configuration? Thanks, Simon — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.