From blowekamp at mail.nih.gov  Mon Dec  5 13:17:59 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Mon, 5 Dec 2016 18:17:59 +0000
Subject: [ITK-dev] Visual Studio 2017 RC
Message-ID: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>

Hello,

Has anyone tried out the new MS Visual Studio 2017 RC with ITK?

Thanks,
Brad

From dzenanz at gmail.com  Tue Dec  6 10:20:18 2016
From: dzenanz at gmail.com (=?UTF-8?B?RMW+ZW5hbiBadWtpxIc=?=)
Date: Tue, 6 Dec 2016 10:20:18 -0500
Subject: [ITK-dev] Visual Studio 2017 RC
In-Reply-To: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>
References: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>
Message-ID: <CAPf2UMQ_NHgP_3FQ=SdozWvCY9B_TnC5RVZWLQP59gVOw40F9A@mail.gmail.com>

I have. It has internal compiler error a few hundred times when compiling
ITK. I submitted the issue to Microsoft. Beta 3 or 4 (I don't remember
which one I tried) compiled ITK without issues - but that version was still
using the old compiler toolchain (v140). 2017 RC uses toolset v141.

Regards,
D?enan

On Mon, Dec 5, 2016 at 1:17 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <
blowekamp at mail.nih.gov> wrote:

> Hello,
>
> Has anyone tried out the new MS Visual Studio 2017 RC with ITK?
>
> Thanks,
> Brad
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161206/000fe147/attachment.html>

From blowekamp at mail.nih.gov  Tue Dec  6 13:14:29 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Tue, 6 Dec 2016 18:14:29 +0000
Subject: [ITK-dev] Visual Studio 2017 RC
In-Reply-To: <CAPf2UMQ_NHgP_3FQ=SdozWvCY9B_TnC5RVZWLQP59gVOw40F9A@mail.gmail.com>
References: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>
 <CAPf2UMQ_NHgP_3FQ=SdozWvCY9B_TnC5RVZWLQP59gVOw40F9A@mail.gmail.com>
Message-ID: <89356520-B449-420C-A87F-9BB1C65F8AD1@mail.nih.gov>

I am not were where to get that ?toolset? version number from. I just downloaded the VS 2017 RC this morning.

I am getting this info from the compiler:

/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 14.0/VC/bin/cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

Here is the build on CDash:
https://open.cdash.org/buildSummary.php?buildid=4673579

It looks like the internal compiler errors have been resolved. Just one relevant failing test.

Brad

On Dec 6, 2016, at 10:20 AM, D?enan Zuki? <dzenanz at gmail.com<mailto:dzenanz at gmail.com>> wrote:

I have. It has internal compiler error a few hundred times when compiling ITK. I submitted the issue to Microsoft. Beta 3 or 4 (I don't remember which one I tried) compiled ITK without issues - but that version was still using the old compiler toolchain (v140). 2017 RC uses toolset v141.

Regards,
D?enan

On Mon, Dec 5, 2016 at 1:17 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:
Hello,

Has anyone tried out the new MS Visual Studio 2017 RC with ITK?

Thanks,
Brad
_______________________________________________
Powered by www.kitware.com<http://www.kitware.com/>

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161206/d6ee98e8/attachment.html>

From blowekamp at mail.nih.gov  Tue Dec  6 13:23:00 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Tue, 6 Dec 2016 18:23:00 +0000
Subject: [ITK-dev] Visual Studio 2017 RC
In-Reply-To: <89356520-B449-420C-A87F-9BB1C65F8AD1@mail.nih.gov>
References: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>
 <CAPf2UMQ_NHgP_3FQ=SdozWvCY9B_TnC5RVZWLQP59gVOw40F9A@mail.gmail.com>
 <89356520-B449-420C-A87F-9BB1C65F8AD1@mail.nih.gov>
Message-ID: <3BFB9F03-677F-4E1C-9913-F0FB6996B626@mail.nih.gov>

Correction: I am not aware of where to get that ?toolset? version number from.

On Dec 6, 2016, at 1:14 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:

I am not were where to get that ?toolset? version number from. I just downloaded the VS 2017 RC this morning.

I am getting this info from the compiler:

/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 14.0/VC/bin/cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

Here is the build on CDash:
https://open.cdash.org/buildSummary.php?buildid=4673579

It looks like the internal compiler errors have been resolved. Just one relevant failing test.

Brad

On Dec 6, 2016, at 10:20 AM, D?enan Zuki? <dzenanz at gmail.com<mailto:dzenanz at gmail.com>> wrote:

I have. It has internal compiler error a few hundred times when compiling ITK. I submitted the issue to Microsoft. Beta 3 or 4 (I don't remember which one I tried) compiled ITK without issues - but that version was still using the old compiler toolchain (v140). 2017 RC uses toolset v141.

Regards,
D?enan

On Mon, Dec 5, 2016 at 1:17 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:
Hello,

Has anyone tried out the new MS Visual Studio 2017 RC with ITK?

Thanks,
Brad
_______________________________________________
Powered by www.kitware.com<http://www.kitware.com/>

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers


_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161206/411adea4/attachment.html>

From brad.king at kitware.com  Tue Dec  6 13:50:16 2016
From: brad.king at kitware.com (Brad King)
Date: Tue, 6 Dec 2016 13:50:16 -0500
Subject: [ITK-dev] Visual Studio 2017 RC
In-Reply-To: <3BFB9F03-677F-4E1C-9913-F0FB6996B626@mail.nih.gov>
References: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>
 <CAPf2UMQ_NHgP_3FQ=SdozWvCY9B_TnC5RVZWLQP59gVOw40F9A@mail.gmail.com>
 <89356520-B449-420C-A87F-9BB1C65F8AD1@mail.nih.gov>
 <3BFB9F03-677F-4E1C-9913-F0FB6996B626@mail.nih.gov>
Message-ID: <5f78ba87-bc03-59a9-e0fa-d7c42d9e6284@kitware.com>

On 12/06/2016 01:23 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
> Correction: I am not aware of where to get that ?toolset? version number from.
> 
>> I am getting this info from the compiler:
>>
>> /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 14.0/VC/bin/cl.exe 
>> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.

You need to use CMake 3.7.1 or above to get proper VS 2017 RC toolset
selection.

-Brad K


From blowekamp at mail.nih.gov  Tue Dec  6 15:11:54 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Tue, 6 Dec 2016 20:11:54 +0000
Subject: [ITK-dev] Visual Studio 2017 RC
In-Reply-To: <5f78ba87-bc03-59a9-e0fa-d7c42d9e6284@kitware.com>
References: <40570EE4-3979-4125-9A81-39FFDBCDBF12@mail.nih.gov>
 <CAPf2UMQ_NHgP_3FQ=SdozWvCY9B_TnC5RVZWLQP59gVOw40F9A@mail.gmail.com>
 <89356520-B449-420C-A87F-9BB1C65F8AD1@mail.nih.gov>
 <3BFB9F03-677F-4E1C-9913-F0FB6996B626@mail.nih.gov>
 <5f78ba87-bc03-59a9-e0fa-d7c42d9e6284@kitware.com>
Message-ID: <7A225D29-56DD-4867-935A-7695588C8535@mail.nih.gov>

Thanks!

I was using CMake 3.7.0 and specified ?Visual Studio 15 Win64?. It looks like it used the VS14 compiler.

I upgraded to CMake 3.7.1, specified ?Visual Studio 15 2017 Win64?, verified it was using the correct cl.exe, and now we have a CDash entry:

https://open.cdash.org/buildSummary.php?buildid=4673682

which now contains some internal compiler errors?.

Brad

> On Dec 6, 2016, at 1:50 PM, Brad King <brad.king at kitware.com> wrote:
> 
> On 12/06/2016 01:23 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
>> Correction: I am not aware of where to get that ?toolset? version number from.
>> 
>>> I am getting this info from the compiler:
>>> 
>>> /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 14.0/VC/bin/cl.exe 
>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
>>> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> You need to use CMake 3.7.1 or above to get proper VS 2017 RC toolset
> selection.
> 
> -Brad K
> 


From dzenanz at gmail.com  Wed Dec  7 18:37:13 2016
From: dzenanz at gmail.com (=?UTF-8?B?RMW+ZW5hbiBadWtpxIc=?=)
Date: Wed, 7 Dec 2016 18:37:13 -0500
Subject: [ITK-dev] Fwd: [Developer Community] Ulzii Luvsanbat posted a new
 comment on "Compiling ITK triggers internal error"
In-Reply-To: <6.7.37282.572.COMMENT.a769b2ad82de06fda7e952dd76e9db37@microsoft.com>
References: <6.7.37282.572.COMMENT.a769b2ad82de06fda7e952dd76e9db37@microsoft.com>
Message-ID: <CAPf2UMQPBfxHmzGyh8538NJF9ii26hiwsmcvv=B3sKEX+Ry0Kg@mail.gmail.com>

---------- Forwarded message ----------
From: <vscommun at microsoft.com>
Date: Wed, Dec 7, 2016 at 6:17 PM
Subject: [Developer Community] Ulzii Luvsanbat posted a new comment on
"Compiling ITK triggers internal error"
To: dzenanz at gmail.com


<http://www.visualstudio.com>

Hi d?enan-zuki?,

A new comment on a *Compiling ITK triggers internal error*
<https://developercommunity.visualstudio.com/comments/6266/view.html> was
posted by Ulzii Luvsanbat on Developer Community:

* Hello, Thanks for this report. We'll look into fixing this for VS2017.
We're also going to add this open source project to our compiler validation
test suites to ensure we don't ship future VS releases that don't compile
ITK sources. Thanks, Ulzii Luvsanbat Visual C++ Team *

View Ulzii Luvsanbat's new comment
<https://developercommunity.visualstudio.com/comments/6266/view.html>

If you do not wish to receive these notifications you can update your
Notification
Settings
<https://developercommunity.visualstudio.com/users/572/c029694a-14cf-4127-b809-54d1678fe43a/preferences.html#/notifyTab>
.

This message from Microsoft is an important part of a program, service, or
product that you or your company purchased or participate in.
Microsoft respects your privacy. Please read our Privacy Statement
<https://www.visualstudio.com/en-us/dn948229>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161207/9f049672/attachment.html>

From blowekamp at mail.nih.gov  Thu Dec  8 10:34:22 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Thu, 8 Dec 2016 15:34:22 +0000
Subject: [ITK-dev] [ITK] [ITK-users] Fwd: [Developer Community] Ulzii
 Luvsanbat posted a new comment on "Compiling ITK triggers internal error"
In-Reply-To: <CAPf2UMQPBfxHmzGyh8538NJF9ii26hiwsmcvv=B3sKEX+Ry0Kg@mail.gmail.com>
References: <6.7.37282.572.COMMENT.a769b2ad82de06fda7e952dd76e9db37@microsoft.com>
 <CAPf2UMQPBfxHmzGyh8538NJF9ii26hiwsmcvv=B3sKEX+Ry0Kg@mail.gmail.com>
Message-ID: <303FFB15-F51A-48A3-AD3A-01CEEA30059F@mail.nih.gov>

Thanks for reporting and forwarding that reported issue. That sounds outstanding that they will try to fix the issue for the VS release, and are also consider adding ITK into their compiler validation tests.

Based on the Experimental build I did:
https://open.cdash.org/viewBuildError.php?buildid=4673717

This looks like the only internal compiler error (ICE) encountered. I hope there are not more ICE encounter after this one.

One thing to note is that with this ICE no tests were able to run, so we don?t know if the code generated has any differences or problems. I wonder if there is a little hack that could be done to work around this ICE issue in itkPrometeType.h, to see if there are any other issues later one?

Brad

On Dec 7, 2016, at 6:37 PM, D?enan Zuki? <dzenanz at gmail.com<mailto:dzenanz at gmail.com>> wrote:


---------- Forwarded message ----------
From: <vscommun at microsoft.com<mailto:vscommun at microsoft.com>>
Date: Wed, Dec 7, 2016 at 6:17 PM
Subject: [Developer Community] Ulzii Luvsanbat posted a new comment on "Compiling ITK triggers internal error"
To: dzenanz at gmail.com<mailto:dzenanz at gmail.com>


[https://developercommunity.visualstudio.com/themes/microsoft/images/visual_studio_logo_small.png] <http://www.visualstudio.com/>

Hi d?enan-zuki?,


A new comment on a Compiling ITK triggers internal error<https://developercommunity.visualstudio.com/comments/6266/view.html> was posted by Ulzii Luvsanbat on Developer Community:


Hello,

Thanks for this report. We'll look into fixing this for VS2017. We're also going to add this open source project to our compiler validation test suites to ensure we don't ship future VS releases that don't compile ITK sources.

Thanks,

Ulzii Luvsanbat

Visual C++ Team


View Ulzii Luvsanbat's new comment<https://developercommunity.visualstudio.com/comments/6266/view.html>



If you do not wish to receive these notifications you can update your Notification Settings<https://developercommunity.visualstudio.com/users/572/c029694a-14cf-4127-b809-54d1678fe43a/preferences.html#/notifyTab>.

This message from Microsoft is an important part of a program, service, or product that you or your company purchased or participate in.
Microsoft respects your privacy. Please read our Privacy Statement<https://www.visualstudio.com/en-us/dn948229>.




[https://developercommunity.visualstudio.com/themes/microsoft/images/Microsoft-logo_rgb_c-gray4.png]

_____________________________________
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users
_______________________________________________
Community mailing list
Community at itk.org
http://public.kitware.com/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161208/55cf8819/attachment.html>

From dzenanz at gmail.com  Thu Dec  8 10:37:58 2016
From: dzenanz at gmail.com (=?UTF-8?B?RMW+ZW5hbiBadWtpxIc=?=)
Date: Thu, 8 Dec 2016 10:37:58 -0500
Subject: [ITK-dev] [ITK] [ITK-users] Fwd: [Developer Community] Ulzii
 Luvsanbat posted a new comment on "Compiling ITK triggers internal error"
In-Reply-To: <303FFB15-F51A-48A3-AD3A-01CEEA30059F@mail.nih.gov>
References: <6.7.37282.572.COMMENT.a769b2ad82de06fda7e952dd76e9db37@microsoft.com>
 <CAPf2UMQPBfxHmzGyh8538NJF9ii26hiwsmcvv=B3sKEX+Ry0Kg@mail.gmail.com>
 <303FFB15-F51A-48A3-AD3A-01CEEA30059F@mail.nih.gov>
Message-ID: <CAPf2UMSEu7H6U-WhDs98S5pCrgB8-BVHsggWdPTstZ5ix+9GRA@mail.gmail.com>

Hopefully they will give me a chance to thoroughly test the fix, in case
they don't do it themselves. There will probably be another update to the
RC release - there was one already.

Regards,
D?enan

On Thu, Dec 8, 2016 at 10:34 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <
blowekamp at mail.nih.gov> wrote:

> Thanks for reporting and forwarding that reported issue. That sounds
> outstanding that they will try to fix the issue for the VS release, and are
> also consider adding ITK into their compiler validation tests.
>
> Based on the Experimental build I did:
> https://open.cdash.org/viewBuildError.php?buildid=4673717
>
> This looks like the only internal compiler error (ICE) encountered. I hope
> there are not more ICE encounter after this one.
>
> One thing to note is that with this ICE no tests were able to run, so we
> don?t know if the code generated has any differences or problems. I wonder
> if there is a little hack that could be done to work around this ICE issue
> in itkPrometeType.h, to see if there are any other issues later one?
>
> Brad
>
> On Dec 7, 2016, at 6:37 PM, D?enan Zuki? <dzenanz at gmail.com> wrote:
>
>
> ---------- Forwarded message ----------
> From: <vscommun at microsoft.com>
> Date: Wed, Dec 7, 2016 at 6:17 PM
> Subject: [Developer Community] Ulzii Luvsanbat posted a new comment on
> "Compiling ITK triggers internal error"
> To: dzenanz at gmail.com
>
>
> <http://www.visualstudio.com/>
>
> Hi d?enan-zuki?,
>
> A new comment on a *Compiling ITK triggers internal error*
> <https://developercommunity.visualstudio.com/comments/6266/view.html> was
> posted by Ulzii Luvsanbat on Developer Community:
>
>
>
> * Hello, Thanks for this report. We'll look into fixing this for VS2017.
> We're also going to add this open source project to our compiler validation
> test suites to ensure we don't ship future VS releases that don't compile
> ITK sources. Thanks, Ulzii Luvsanbat Visual C++ Team *
>
> View Ulzii Luvsanbat's new comment
> <https://developercommunity.visualstudio.com/comments/6266/view.html>
>
> If you do not wish to receive these notifications you can update your Notification
> Settings
> <https://developercommunity.visualstudio.com/users/572/c029694a-14cf-4127-b809-54d1678fe43a/preferences.html#/notifyTab>
> .
>
> This message from Microsoft is an important part of a program, service, or
> product that you or your company purchased or participate in.
> Microsoft respects your privacy. Please read our Privacy Statement
> <https://www.visualstudio.com/en-us/dn948229>.
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-users
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161208/ae19bf21/attachment.html>

From dzenanz at gmail.com  Thu Dec  8 14:05:42 2016
From: dzenanz at gmail.com (=?UTF-8?B?RMW+ZW5hbiBadWtpxIc=?=)
Date: Thu, 8 Dec 2016 14:05:42 -0500
Subject: [ITK-dev] Fwd: [Developer Community] Ulzii Luvsanbat posted a new
 solution to "Compiling ITK triggers internal error"
In-Reply-To: <6.7.37951.572.SOLUTION.ca0f8282a528bda939595b4871560509@microsoft.com>
References: <6.7.37951.572.SOLUTION.ca0f8282a528bda939595b4871560509@microsoft.com>
Message-ID: <CAPf2UMQ03W-nSUCMbvnmCCOjBgepQmiJTeMy_JOSEqhcTVxNZg@mail.gmail.com>

I guess they are nearing release.
---------- Forwarded message ----------
From: <vscommun at microsoft.com>
Date: Dec 8, 2016 13:23
Subject: [Developer Community] Ulzii Luvsanbat posted a new solution to
"Compiling ITK triggers internal error"
To: <dzenanz at gmail.com>
Cc:

<http://www.visualstudio.com>
>
> Hi d?enan-zuki?,
>
> A new solution to the problem "Compiling ITK triggers internal error" was
> posted by Ulzii Luvsanbat on Developer Community:
>
> * Hello, We've validated that with /Od and /O2 compilations with our
> latest compiler for VS2017 final release, this bug doesn't exist. As I've
> mentioned we'll add ITK and VTK projects into our compiler validation test
> suites going forward. Thanks, Ulzii Luvsanbat Visual C++ Team *
>
> View Ulzii Luvsanbat's new solution
> <https://developercommunity.visualstudio.com/content/problem/4679/compiling-itk-triggers-internal-error.html>
>
> If you do not wish to receive these notifications you can update your Notification
> Settings
> <https://developercommunity.visualstudio.com/users/572/c029694a-14cf-4127-b809-54d1678fe43a/preferences.html#/notifyTab>
> .
>
> This message from Microsoft is an important part of a program, service, or
> product that you or your company purchased or participate in.
> Microsoft respects your privacy. Please read our Privacy Statement
> <https://www.visualstudio.com/en-us/dn948229>.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161208/4d124fda/attachment.html>

From blowekamp at mail.nih.gov  Mon Dec 12 11:17:35 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Mon, 12 Dec 2016 16:17:35 +0000
Subject: [ITK-dev] ITK Link errors: Template parent not exported
Message-ID: <85C190AF-D1C5-48E7-B9E4-0CEC59493D79@mail.nih.gov>

Hello,

I just wanted to report what I see is going on in two simular cases of link errors in ITK and SimpleITK.


The first is ITK with VS12 and shared libraries and CMAKE_WINDOWS_ALL_SYMBOLS:BOOL=ON. It is here on the ITK dashboard [1] and here is the error:

itkPolylineMask2DImageFilterTest.cxx.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) const itk::Path,2>::`vftable'" (__imp_??_7?$Path at NV?$ContinuousIndex at N$01 at itk@@$01 at itk@@6B@) referenced in function "protected: virtual __cdecl itk::PolyLineParametricPath<2>::~PolyLineParametricPath<2>(void)" (??1?$PolyLineParametricPath@$01 at itk@@MEAA at XZ)

This error began occurring after explicit exporting of the explicitly instantiated of PolyLineParametericPath<2> was merged ( to fix other linking error )[3]. The missing symbol?s class that class's parent itk::Path<2> class, which does not get explicitly instantiated or explicitly exported.


The second linking error seems very similar. It is on the SimpleITK dashboard also with VS12 and shared libraries. This configuration does not have the CMAKE_WINDOWS_ALL_SYMBOLS enabled, just the default explicit export for VS. The errors are here [2]:

ITKOptimizersv4-4.11.lib(ITKOptimizersv4-4.11.dll) : error LNK2005: "public: virtual void __cdecl itk::ObjectToObjectOptimizerBaseTemplate::StartOptimization(bool)" (?StartOptimization@?$ObjectToObjectOptimizerBaseTemplate at N@itk@@UEAAX_N at Z) already defined in sitkImageRegistrationMethod.obj [C:\d\vs11\SimpleITK-build\SimpleITK-build\Code\Registration\src\SimpleITKRegistration.vcxproj] [C:\d\vs11\SimpleITK-build\SimpleITK.vcxproj]

This is similar because the itk::ObjectToObjectOptimiserBaseTemplate class is a parent of the explicitly exported and instantiated itk::SingleValuedNonLinearVnlOptimizerv4.

I recall a couple comments related to exporting parent template classes here:
http://review.source.kitware.com/#/c/20020/2/Modules/Numerics/Optimizersv4/include/itkLBFGSOptimizerBasev4.h
http://review.source.kitware.com/#/c/20020/6/Modules/Numerics/Optimizersv4/include/itkLBFGSOptimizerBasev4.h


My hypothesis with these error is: VS12 requires all parents in a exported explicitly instantiated template class to be exported for correct linking.

Anyone have any experience to confirm this or additional information?

Thanks,
Brad

[1] https://open.cdash.org/viewBuildError.php?buildid=4681054
[2] https://open.cdash.org/viewBuildError.php?buildid=4680972
[3] https://github.com/InsightSoftwareConsortium/ITK/commit/a94bc525c0f5911b71fcacb647245efd8306990c

From blowekamp at mail.nih.gov  Wed Dec 14 09:03:26 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Wed, 14 Dec 2016 14:03:26 +0000
Subject: [ITK-dev] [ITK-users] Error conversion from
In-Reply-To: <CAAq9_B7fox6AL_mc-1s5CdqfNnj7zBkH0tZcXJXZTZ72se+3Ww@mail.gmail.com>
References: <CAAq9_B7fox6AL_mc-1s5CdqfNnj7zBkH0tZcXJXZTZ72se+3Ww@mail.gmail.com>
Message-ID: <3ACA34EA-C664-4D0C-BB46-5010BBE0EF71@mail.nih.gov>

This error message is suppose to be an improvement from the default to indicate why the code/filter does not work with the template parameters you selected. 

Here is the key part:
> itk::Concept::IsFloatingPoint<short int>::Constraints::False


This a a concept check to verify the template parameter is a floating point type which is required by the algorithm/filter/code. The type ?short int? is not a floating point type, so it generates a compilation error.

I have no clue what is causing it, as you didn?t include any code :)

If you look at the all error messages it should indicate the origin of the error. Most likely the cause is: you provided a "short" type for a template parameter (or image type) to a filter or algorithm which requires a floating point type.

HTH,
Brad

> On Dec 14, 2016, at 8:56 AM, Nico Del Piano <ndel314 at gmail.com> wrote:
> 
> Hello ITK community,
> 
> I'm struggling with an error and I don't understand why it's happening:
> 
> 
> /usr/local/include/ITK-4.11/itkConceptChecking.h:796:28: error:
> conversion from ?itk::Concept::IsFloatingPoint<short
> int>::Constraints::FalseT {aka
> itk::Concept::Detail::UniqueType_bool<false>}? to non-scalar type
> ?itk::Concept::IsFloatingPoint<short int>::Constraints::IntegralT {aka
> itk::Concept::Detail::UniqueType_bool<true>}? requested
>      IntegralT a = FalseT();
>                           ^
> /usr/local/include/ITK-4.11/itkConceptChecking.h:797:28: error:
> conversion from ?itk::Concept::IsFloatingPoint<short
> int>::Constraints::FalseT {aka
> itk::Concept::Detail::UniqueType_bool<false>}? to non-scalar type
> ?itk::Concept::IsFloatingPoint<short int>::Constraints::ExactT {aka
> itk::Concept::Detail::UniqueType_bool<true>}? requested
>      ExactT    b = FalseT();
> 
> 
> Any hint of what could be causing this? If you need the whole error I
> can paste it.
> 
> Thanks,
> 
> Nico.
> _____________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-users


From isaiah.norton at gmail.com  Fri Dec 16 16:24:43 2016
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Fri, 16 Dec 2016 16:24:43 -0500
Subject: [ITK-dev] ITK+static+wrapping [ref: 21857 "Enable singleton program
	global timestamp"]
Message-ID: <CADFtqoq+0kvvBPKKOCL9Tz_hPbjC8=uD6vY7DAK5JsOnwLiymA@mail.gmail.com>

I was added as a reviewer on #21857 [1], but my comment is more general, so
I don't think gerrit is the best place for it.

The background of that merge request is [2], where a user demonstrated
inconsistent modification times when objects are modified by functions from
different modules, via Python, with ITK compiled in static library mode.
The underlying cause is that each module has a separate, private instance
of the GlobalTimeStamp, so the operations increment different counter
variables.

The proposed solution in [1] is to provide a singleton-like object with a
settable internal pointer, initialized by the Python loader to point to a
single instance in ITKCommon.

The technical implementation looks ok, but the original situation in [2] is
strange:

What is the rationale behind creating so many separate, statically-linked
Python modules? (78 `_ITK*Python.so` files on my machine). Creating a
single bundle instead should resolve the original issue, and might also
reduce the size of the final library [3].

Additionally, I am wondering if cross-module `dynamic_cast` works correctly
in the current situation -- because the typeinfos in each static module .so
have different addresses [4]. (I'm not sure how to create a situation to
test this from Python)

Best,
Isaiah

[1] http://review.source.kitware.com/#/c/21857/4
[2] https://issues.itk.org/jira/browse/ITK-3456

[3] As a point of reference, the total size of the static `_ITK*Python.so`
files on my mac is about 670MB. If I manually link everything into a single
file, the size drops to about 430MB, presumably due to deduplication of
symbols. Further reduction might be possible: there are still many
duplicate symbols which may not be merged due to differing offsets.

[4] https://gist.github.com/ihnorton/6691645ede869d6bc6c25b143fbf3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161216/2d245f44/attachment.html>

From matt.mccormick at kitware.com  Sat Dec 17 10:41:06 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sat, 17 Dec 2016 10:41:06 -0500
Subject: [ITK-dev] ITK+static+wrapping [ref: 21857 "Enable singleton
	program global timestamp"]
In-Reply-To: <CADFtqoq+0kvvBPKKOCL9Tz_hPbjC8=uD6vY7DAK5JsOnwLiymA@mail.gmail.com>
References: <CADFtqoq+0kvvBPKKOCL9Tz_hPbjC8=uD6vY7DAK5JsOnwLiymA@mail.gmail.com>
Message-ID: <CALzTN-Q_RpKMEekQ-cgzHQaF8eV7R_VpE+QaNKxn-d-9t0ZuGw@mail.gmail.com>

Hi Isaiah,

Here is some more information and background.


> What is the rationale behind creating so many separate, statically-linked
> Python modules? (78 `_ITK*Python.so` files on my machine). Creating a single
> bundle instead should resolve the original issue, and might also reduce the
> size of the final library [3].

For background, the GlobalTimeStamp, is a very important variable in
ITK (and VTK). This is an atomic integer that gets incremented when
any itk::Object (most classes in ITK) is "Modified", i.e. changed to
note that it should be updated in a processing pipeline. So, almost
all ITK-based code needs it, and it needs to be global across the
entire program.

The GlobalTimeStamp lives in and is used my itk::TimeStamp.cxx, and it
is incremented on every call to ::Modified(). The itk::TimeStamp class
is linked into libITKCommon.

When ITK is built with shared libraries, libITKCommon is shared, and
everything shares the GlobalTimeStamp. When ITK is built with static
libraries, every binary that links in libITKCommon will get its own
GlobalTimeStamp.

Unfortunately, a shared libITKCommon is not always possible. For the
official Python packaging format, wheels, native libraries are not yet
officially supported [1].

The advantages of not linking everything into one, giant, monolithic
`_ITK*Python.so` are that 1) we can lazily load only the parts of the
library that we need, and 2) the brilliant ITK community members can
extend ITK to create their own ITK Python module. For example, see the
awesome ITKMinimalPathExtraction [2] or ITKIsotropicWavelets [3]
modules.

While I also investigated, for example, using CMake object libraries
to make itk::TimeStamp an exported symbol in _ITKCommonPython.so and
only linked there [4], this is a more complex build configuration.
Additionally, according to the Python documentation, exporting extra
symbols in a CPython extension module is officially not supported [5].
In practice, I have found that extra symbols can segfault the process
on module import with Python 3.5 on Windows. So, the sharing is done
the officially supported way, via PyCapsule.


> Additionally, I am wondering if cross-module `dynamic_cast` works correctly
> in the current situation -- because the typeinfos in each static module .so
> have different addresses [4]. (I'm not sure how to create a situation to
> test this from Python)

Yes, since the Python wrapping covers the entire toolkit, it is an
excellent stress test for the dynamic_cast issue. When we developed
the dynamic_cast patch, we used Python wrapping with static libraries
and experimentally enabled hidden symbols by default [6]. Without the
dynamic_cast fix, the Python tests failed, and with the fix, they
pass. It turns out that we missed some mark-up on a few classes as
indicated by warnings in the Python wrapping and non-wrapping test
failures, but we are working on resolving those now.

Thanks,
Matt


[1] https://mail.python.org/pipermail/wheel-builders/2016-April/000090.html

[2] https://github.com/InsightSoftwareConsortium/ITKMinimalPathExtraction

[3] https://github.com/phcerdan/ITKIsotropicWavelets

[4] https://github.com/thewtex/ITK/commits/thewtex-PythonModifiedTime55

[5] https://docs.python.org/3.5/extending/extending.html#providing-a-c-api-for-an-extension-module

[6] http://review.source.kitware.com/#/c/21766/

From matt.mccormick at kitware.com  Sat Dec 17 12:01:10 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sat, 17 Dec 2016 12:01:10 -0500
Subject: [ITK-dev] RFI on the NLM Strategic Plan
Message-ID: <CALzTN-R8ucssgasu-LWiUfBADfGFC1X15iV423LjHad_w9hRww@mail.gmail.com>

Hi,

The National Library of Medicine (NLM) has driven open science and
reproducible research long before the recent surge in popularity of
the movement. Not only did the NLM start the Insight Toolkit (ITK)
project in 1999, but it has continuously enabled it to thrive by
supporting community development, maintenance, and algorithmic and
technological advances to this day [1] [2].

Open science needs active communities, supported communities,
standards, open-source tools, strong ties will commercial / clinical
efforts, high-quality practices, transparency, and more - and those
are exactly the strengths of our community's toolkits, applications,
and projects. We should to encourage the NLM (NIH, DHHS, US
Government) to continue to prioritize these efforts via their funding.

The NLM has called for Request for Information (RFI) on the strategic
plan for the institute:

  https://grants.nih.gov/grants/guide/notice-files/NOT-LM-17-002.html

that is due by January 9th. Please consider letting the NLM know how
important their role is in open science and open source.


Thanks,
Matt

[1] https://itk.org/ITK/project/about.html

[2] http://journal.frontiersin.org/article/10.3389/fninf.2014.00013/full

From mohammedrashadkm at gmail.com  Tue Dec 20 04:48:43 2016
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Tue, 20 Dec 2016 10:48:43 +0100
Subject: [ITK-dev] installed ITK cannot be moved due to absolute path
In-Reply-To: <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
References: <CANNqv9eKZygjeSgdauFADK6jev2V9Q4Bhk8gfP=GkR5ngLfoGA@mail.gmail.com>
 <CAPf2UMTo6LY09u1gKxa+MPjOgyQjMh25ADHSdpv4wTc3GRzbZA@mail.gmail.com>
 <CANNqv9dC9F6PHSyrLfnqY2NbA8dSDxnD-kzEKTdUqwhW_Mea8A@mail.gmail.com>
 <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
Message-ID: <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>

Hello all,

Is there a simple FindITK.cmake which can be used instead of config and
targets cmake files?

in my install tree, in ITKTargets-release.Cmake there exists absolute path
for include and lib file.

My install tree of ITK does not work on a different machine unless I copy
them too exact same directory where I installed on machine.

This goes against portability and it is cmake who is doing this work.

Here is code in ITKTargets-release.cmake

set_property(TARGET ITKMetaIO APPEND PROPERTY IMPORTED_CONFIGURATIONS
RELEASE)
set_target_properties(ITKMetaIO PROPERTIES
  IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/ITKMetaIO-4.10.lib"
  IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
"C:/dashboard/otb/install_sb_x86/lib/zdll.lib;comctl32;wsock32"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/ITKMetaIO-4.10.dll"
  )

see the absolute path to C:/dashboard/otb/install_sb_x86/lib/zdll.lib

so if on a different machine no matter where I copy these cmake files for
ITK, I must have zdll.lib in C:/dashboard/otb/install_sb_x86/lib/
and same goes for fftw, expat etc.. if enabled.

A simple find_package searching for for include and headers is portable
than config files. Right now even copying the files on same compiler won't
work.
But in reality there is no technical issues.

Is anyone aware of a better way other than manually updating those absolute
path to zdll.lib

On Tue, May 24, 2016 at 1:21 AM, Matt McCormick <matt.mccormick at kitware.com>
wrote:

> Hi Rashad,
>
> It looks like MXE is configured to use system versions of EXPAT, HDF5,
> JPEG, PNG, TIFF, and ZLIB:
>
>   https://github.com/mxe/mxe/blob/4135f9b1227ba56b92ceb8a9820163
> 70ad5c8894/src/itk.mk#L28-L33
>
> USE_SYSTEM could be disabled for these libraries.
>
> Or, it may be possible for the module system to learn relative
> locations of these libraries with ITK_USE_SYSTEM*. But, it would work
> best if these projects were configured with CMake, create a
> <project>Config.cmake or <project>-config.cmake file, and use relative
> paths internally.
>
> HTH,
> Matt
>
> On Tue, May 10, 2016 at 5:25 PM, Rashad Kanavath
> <mohammedrashadkm at gmail.com> wrote:
> >
> >
> > On Tue, May 10, 2016 at 10:50 PM, D?enan Zuki? <dzenanz at gmail.com>
> wrote:
> >>
> >> Hi Rashad,
> >>
> >> a few months ago relative paths were completely removed from CMake,
> >> because they were never fully implemented. Have you followed
> recommendations
> >> from here for cross-compiling?
> >
> >
> > Yes. indeed. I had updated the mxe/src/itk.mk for several versions of
> ITK!
> >
> > Regarding relative path in cmake, I don't understand.  I didn't use cmake
> > specific REL_PATH.
> >>
> >>
> >> As for integrating your changes into ITK, you should submit a patch
> >> following the instructions here. If your changes don't break anything,
> they
> >> are likely to be integrated.
> >
> >
> > issue here is a bit different. For all libitk* stuff the story ends well.
> > For thirdparties, zlib, expat etc.. it is good idea to put the full path
> > because we don't know if they are in same install directory as ITK or
> not.
> > But this make the installed cmake modules non-portable even to a
> different
> > location on the same disk.
> >
> > Now if anyone want to provide a distributable setup of ITK. patch the
> > generated cmake files with sed and then copy it. This is what I am doing
> > right now!
> > A simple not perfect solution is to have all thirdparties make
> > <LIBRARY>_PREFIX variable inside the ITKConfig.cmake
> >
> > and for each library we use <LIBRARY>_PREFIX/include and
> > <LIBRARY>_PREFIX/lib
> >
> >
> > Another option is to avoid full path directly inside cmake module files
> and
> > put find_package() calls in the install tree.
> >
> > As these files are autogenerated by cmake, don't know what is possible.
> >
> >
> >
> >
> >
> >>
> >> Regards,
> >> D?enan
> >>
> >> On Mon, May 9, 2016 at 4:27 PM, Rashad Kanavath
> >> <mohammedrashadkm at gmail.com> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I have some issue when copying ITK install directory to a different
> >>> system. I agree this is not usual and may not appear on a linux distro
> or
> >>> windows.
> >>>
> >>> My requirement is bit different. I cross-compile ITK and then use the
> >>> binaries on Windows. Using dll and headers are fine. But the installed
> cmake
> >>> files are a problem. They have absolute path in ITK-4.8/Modules/*.cmake
> >>> files. It is not in all .cmake files even though I put a wildcard
> there..
> >>>
> >>> For a easy and quick workaround. I rely on mighty sed command to insert
> >>> something into installed cmake file.
> >>>
> >>> For example see this;
> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
> >>>
> >>> set(CMAKE_IMPORT_FILE_VERSION 1)
> >>> set(LIB_INSTALL_PREFIX)
> >>> get_filename_component(CURRENT_FILE_DIR "${CMAKE_CURRENT_LIST_FILE}"
> >>> PATH)
> >>> get_filename_component(LIB_INSTALL_PREFIX "${CURRENT_FILE_DIR}" PATH)
> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
> PATH)
> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
> PATH)
> >>>
> >>> and at last:
> >>>
> >>> $(SED) -i 's,$(PREFIX)/$(TARGET),\${LIB_INSTALL_PREFIX},g'
> >>> 'lib/cmake/ITK-$(ITK_VER)/ITKTargets-release.cmake'
> >>>
> >>> I would like to have this patch inside the other .cmake files in the
> >>> installation and avoid the sed commands during post-installation
> >>>
> >>> Here is the list of cmake files that needs this change.
> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
> >>> lib/cmake/ITK-4.8/Modules/ITKZLIB.cmake
> >>> lib/cmake/ITK-4.8/Modules/ITKExpat.cmake
> >>> lib/cmake/ITK-4.8/Modules/ITKHDF5.cmake
> >>> lib/cmake/ITK-4.8/Modules/ITKJPEG.cmake
> >>> lib/cmake/ITK-4.8/Modules/ITKTIFF.cmake
> >>> lib/cmake/ITK-4.8/Modules/ITKPNG.cmake
> >>>
> >>> So is it possible to make the change into future version of ITK?
> >>>
> >>> The major issue here is those cmake files are generated by cmake. Is
> >>> there a way cmake could use relative path ?
> >>>
> >>>
> >>> --
> >>> Regards,
> >>>    Rashad
> >>>
> >>> _______________________________________________
> >>> Powered by www.kitware.com
> >>>
> >>> Visit other Kitware open-source projects at
> >>> http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Kitware offers ITK Training Courses, for more information visit:
> >>> http://kitware.com/products/protraining.php
> >>>
> >>> Please keep messages on-topic and check the ITK FAQ at:
> >>> http://www.itk.org/Wiki/ITK_FAQ
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://public.kitware.com/mailman/listinfo/insight-developers
> >>>
> >>
> >
> >
> >
> > --
> > Regards,
> >    Rashad
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://kitware.com/products/protraining.php
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/insight-developers
> >
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161220/b4a0fd7e/attachment.html>

From dzenanz at gmail.com  Tue Dec 20 10:15:03 2016
From: dzenanz at gmail.com (=?UTF-8?B?RMW+ZW5hbiBadWtpxIc=?=)
Date: Tue, 20 Dec 2016 10:15:03 -0500
Subject: [ITK-dev] installed ITK cannot be moved due to absolute path
In-Reply-To: <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>
References: <CANNqv9eKZygjeSgdauFADK6jev2V9Q4Bhk8gfP=GkR5ngLfoGA@mail.gmail.com>
 <CAPf2UMTo6LY09u1gKxa+MPjOgyQjMh25ADHSdpv4wTc3GRzbZA@mail.gmail.com>
 <CANNqv9dC9F6PHSyrLfnqY2NbA8dSDxnD-kzEKTdUqwhW_Mea8A@mail.gmail.com>
 <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
 <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>
Message-ID: <CAPf2UMRTmOMG9CON1w1X+-GUYzmcNGch5bu0dxq31_WVpT-O8g@mail.gmail.com>

Hi Rashad,

one way to generate install tree in a different location is by
changing CMAKE_INSTALL_PREFIX in CMake, reconfiguring, regenerating
project, the building the INSTALL target. That should generate the install
tree in your desired location.

Regards,
D?enan

On Tue, Dec 20, 2016 at 4:48 AM, Rashad Kanavath <mohammedrashadkm at gmail.com
> wrote:

> Hello all,
>
> Is there a simple FindITK.cmake which can be used instead of config and
> targets cmake files?
>
> in my install tree, in ITKTargets-release.Cmake there exists absolute path
> for include and lib file.
>
> My install tree of ITK does not work on a different machine unless I copy
> them too exact same directory where I installed on machine.
>
> This goes against portability and it is cmake who is doing this work.
>
> Here is code in ITKTargets-release.cmake
>
> set_property(TARGET ITKMetaIO APPEND PROPERTY IMPORTED_CONFIGURATIONS
> RELEASE)
> set_target_properties(ITKMetaIO PROPERTIES
>   IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/ITKMetaIO-4.10.lib"
>   IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "C:/dashboard/otb/install_sb_
> x86/lib/zdll.lib;comctl32;wsock32"
>   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/ITKMetaIO-4.10.dll"
>   )
>
> see the absolute path to C:/dashboard/otb/install_sb_x86/lib/zdll.lib
>
> so if on a different machine no matter where I copy these cmake files for
> ITK, I must have zdll.lib in C:/dashboard/otb/install_sb_x86/lib/
> and same goes for fftw, expat etc.. if enabled.
>
> A simple find_package searching for for include and headers is portable
> than config files. Right now even copying the files on same compiler won't
> work.
> But in reality there is no technical issues.
>
> Is anyone aware of a better way other than manually updating those
> absolute path to zdll.lib
>
> On Tue, May 24, 2016 at 1:21 AM, Matt McCormick <
> matt.mccormick at kitware.com> wrote:
>
>> Hi Rashad,
>>
>> It looks like MXE is configured to use system versions of EXPAT, HDF5,
>> JPEG, PNG, TIFF, and ZLIB:
>>
>>   https://github.com/mxe/mxe/blob/4135f9b1227ba56b92ceb8a98201
>> 6370ad5c8894/src/itk.mk#L28-L33
>>
>> USE_SYSTEM could be disabled for these libraries.
>>
>> Or, it may be possible for the module system to learn relative
>> locations of these libraries with ITK_USE_SYSTEM*. But, it would work
>> best if these projects were configured with CMake, create a
>> <project>Config.cmake or <project>-config.cmake file, and use relative
>> paths internally.
>>
>> HTH,
>> Matt
>>
>> On Tue, May 10, 2016 at 5:25 PM, Rashad Kanavath
>> <mohammedrashadkm at gmail.com> wrote:
>> >
>> >
>> > On Tue, May 10, 2016 at 10:50 PM, D?enan Zuki? <dzenanz at gmail.com>
>> wrote:
>> >>
>> >> Hi Rashad,
>> >>
>> >> a few months ago relative paths were completely removed from CMake,
>> >> because they were never fully implemented. Have you followed
>> recommendations
>> >> from here for cross-compiling?
>> >
>> >
>> > Yes. indeed. I had updated the mxe/src/itk.mk for several versions of
>> ITK!
>> >
>> > Regarding relative path in cmake, I don't understand.  I didn't use
>> cmake
>> > specific REL_PATH.
>> >>
>> >>
>> >> As for integrating your changes into ITK, you should submit a patch
>> >> following the instructions here. If your changes don't break anything,
>> they
>> >> are likely to be integrated.
>> >
>> >
>> > issue here is a bit different. For all libitk* stuff the story ends
>> well.
>> > For thirdparties, zlib, expat etc.. it is good idea to put the full path
>> > because we don't know if they are in same install directory as ITK or
>> not.
>> > But this make the installed cmake modules non-portable even to a
>> different
>> > location on the same disk.
>> >
>> > Now if anyone want to provide a distributable setup of ITK. patch the
>> > generated cmake files with sed and then copy it. This is what I am doing
>> > right now!
>> > A simple not perfect solution is to have all thirdparties make
>> > <LIBRARY>_PREFIX variable inside the ITKConfig.cmake
>> >
>> > and for each library we use <LIBRARY>_PREFIX/include and
>> > <LIBRARY>_PREFIX/lib
>> >
>> >
>> > Another option is to avoid full path directly inside cmake module files
>> and
>> > put find_package() calls in the install tree.
>> >
>> > As these files are autogenerated by cmake, don't know what is possible.
>> >
>> >
>> >
>> >
>> >
>> >>
>> >> Regards,
>> >> D?enan
>> >>
>> >> On Mon, May 9, 2016 at 4:27 PM, Rashad Kanavath
>> >> <mohammedrashadkm at gmail.com> wrote:
>> >>>
>> >>> Hello all,
>> >>>
>> >>> I have some issue when copying ITK install directory to a different
>> >>> system. I agree this is not usual and may not appear on a linux
>> distro or
>> >>> windows.
>> >>>
>> >>> My requirement is bit different. I cross-compile ITK and then use the
>> >>> binaries on Windows. Using dll and headers are fine. But the
>> installed cmake
>> >>> files are a problem. They have absolute path in
>> ITK-4.8/Modules/*.cmake
>> >>> files. It is not in all .cmake files even though I put a wildcard
>> there..
>> >>>
>> >>> For a easy and quick workaround. I rely on mighty sed command to
>> insert
>> >>> something into installed cmake file.
>> >>>
>> >>> For example see this;
>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>> >>>
>> >>> set(CMAKE_IMPORT_FILE_VERSION 1)
>> >>> set(LIB_INSTALL_PREFIX)
>> >>> get_filename_component(CURRENT_FILE_DIR "${CMAKE_CURRENT_LIST_FILE}"
>> >>> PATH)
>> >>> get_filename_component(LIB_INSTALL_PREFIX "${CURRENT_FILE_DIR}" PATH)
>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>> PATH)
>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>> PATH)
>> >>>
>> >>> and at last:
>> >>>
>> >>> $(SED) -i 's,$(PREFIX)/$(TARGET),\${LIB_INSTALL_PREFIX},g'
>> >>> 'lib/cmake/ITK-$(ITK_VER)/ITKTargets-release.cmake'
>> >>>
>> >>> I would like to have this patch inside the other .cmake files in the
>> >>> installation and avoid the sed commands during post-installation
>> >>>
>> >>> Here is the list of cmake files that needs this change.
>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKZLIB.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKExpat.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKHDF5.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKJPEG.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKTIFF.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKPNG.cmake
>> >>>
>> >>> So is it possible to make the change into future version of ITK?
>> >>>
>> >>> The major issue here is those cmake files are generated by cmake. Is
>> >>> there a way cmake could use relative path ?
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>>    Rashad
>> >>>
>> >>> _______________________________________________
>> >>> Powered by www.kitware.com
>> >>>
>> >>> Visit other Kitware open-source projects at
>> >>> http://www.kitware.com/opensource/opensource.html
>> >>>
>> >>> Kitware offers ITK Training Courses, for more information visit:
>> >>> http://kitware.com/products/protraining.php
>> >>>
>> >>> Please keep messages on-topic and check the ITK FAQ at:
>> >>> http://www.itk.org/Wiki/ITK_FAQ
>> >>>
>> >>> Follow this link to subscribe/unsubscribe:
>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >    Rashad
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Kitware offers ITK Training Courses, for more information visit:
>> > http://kitware.com/products/protraining.php
>> >
>> > Please keep messages on-topic and check the ITK FAQ at:
>> > http://www.itk.org/Wiki/ITK_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/insight-developers
>> >
>>
>
>
>
> --
> Regards,
>    Rashad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161220/ed3f06aa/attachment.html>

From mohammedrashadkm at gmail.com  Wed Dec 21 09:03:00 2016
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Wed, 21 Dec 2016 15:03:00 +0100
Subject: [ITK-dev] installed ITK cannot be moved due to absolute path
In-Reply-To: <CAPf2UMRTmOMG9CON1w1X+-GUYzmcNGch5bu0dxq31_WVpT-O8g@mail.gmail.com>
References: <CANNqv9eKZygjeSgdauFADK6jev2V9Q4Bhk8gfP=GkR5ngLfoGA@mail.gmail.com>
 <CAPf2UMTo6LY09u1gKxa+MPjOgyQjMh25ADHSdpv4wTc3GRzbZA@mail.gmail.com>
 <CANNqv9dC9F6PHSyrLfnqY2NbA8dSDxnD-kzEKTdUqwhW_Mea8A@mail.gmail.com>
 <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
 <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>
 <CAPf2UMRTmOMG9CON1w1X+-GUYzmcNGch5bu0dxq31_WVpT-O8g@mail.gmail.com>
Message-ID: <CANNqv9fFF4ukPPy8KSTDe+WWuCdqZDUz5=MLQN81V1Sf8j9Rpw@mail.gmail.com>

Hello D?enan,

Thanks for your reply.  Unfortunately, this won't work in my case. I will
try to explain it.

I have installed itk in my system say: c:/projects/itk_install

now I copy itk_install directory to another system of my colleague. If
he/she is copying my "itk_install" folder into any directory other than
c:/projects/, itk build is useless.
cmake says it cannot find file c:/projects/itk_install/lib/ITKxxxxx.dll
etc..

This error is coming from
c:/projects/itk_install/lib/cmake/ITK-4.10/ITKTargets-release.cmake. Note
that this file is generated by cmake.

So I have two options:
1. ask to copy "itk_install" directory to c:/projects/itk_install (easy, )
2. copy "itk_install" directory anywhere but search in
<your-install-prefix>/lib/cmake/ITK-4.10 and replace all occurrence of
c:/projects/itk_install with <your-install-prefix>

Second solution is more awful compared to first. So for now, I insist on
first option. But after a couple of such installation of "itk_install", it
seems bad to me.
Like I mentioned in last thread, technically my itk_install could be reused
if cmake does not have absolute path in the install tree for ZLIB, fftw
etc..

FYI, there are other projects which does same thing and for them I have a
custom Find<Package>.cmake in source tree. So don't care what ever they
have in their lib/cmake/<Package> files

If ITK devs can provide FindITK.cmake , then we could reuse that. Instead
of ITKConfig.cmake stuff.

Hope I explained case well. Let me know if you need any more information.

Appreciate your help in solving this.


On Tue, Dec 20, 2016 at 4:15 PM, D?enan Zuki? <dzenanz at gmail.com> wrote:

> Hi Rashad,
>
> one way to generate install tree in a different location is by
> changing CMAKE_INSTALL_PREFIX in CMake, reconfiguring, regenerating
> project, the building the INSTALL target. That should generate the install
> tree in your desired location.
>
> Regards,
> D?enan
>
> On Tue, Dec 20, 2016 at 4:48 AM, Rashad Kanavath <
> mohammedrashadkm at gmail.com> wrote:
>
>> Hello all,
>>
>> Is there a simple FindITK.cmake which can be used instead of config and
>> targets cmake files?
>>
>> in my install tree, in ITKTargets-release.Cmake there exists absolute
>> path for include and lib file.
>>
>> My install tree of ITK does not work on a different machine unless I copy
>> them too exact same directory where I installed on machine.
>>
>> This goes against portability and it is cmake who is doing this work.
>>
>> Here is code in ITKTargets-release.cmake
>>
>> set_property(TARGET ITKMetaIO APPEND PROPERTY IMPORTED_CONFIGURATIONS
>> RELEASE)
>> set_target_properties(ITKMetaIO PROPERTIES
>>   IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/ITKMetaIO-4.10.lib"
>>   IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
>> "C:/dashboard/otb/install_sb_x86/lib/zdll.lib;comctl32;wsock32"
>>   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/ITKMetaIO-4.10.dll"
>>   )
>>
>> see the absolute path to C:/dashboard/otb/install_sb_x86/lib/zdll.lib
>>
>> so if on a different machine no matter where I copy these cmake files for
>> ITK, I must have zdll.lib in C:/dashboard/otb/install_sb_x86/lib/
>> and same goes for fftw, expat etc.. if enabled.
>>
>> A simple find_package searching for for include and headers is portable
>> than config files. Right now even copying the files on same compiler won't
>> work.
>> But in reality there is no technical issues.
>>
>> Is anyone aware of a better way other than manually updating those
>> absolute path to zdll.lib
>>
>> On Tue, May 24, 2016 at 1:21 AM, Matt McCormick <
>> matt.mccormick at kitware.com> wrote:
>>
>>> Hi Rashad,
>>>
>>> It looks like MXE is configured to use system versions of EXPAT, HDF5,
>>> JPEG, PNG, TIFF, and ZLIB:
>>>
>>>   https://github.com/mxe/mxe/blob/4135f9b1227ba56b92ceb8a98201
>>> 6370ad5c8894/src/itk.mk#L28-L33
>>>
>>> USE_SYSTEM could be disabled for these libraries.
>>>
>>> Or, it may be possible for the module system to learn relative
>>> locations of these libraries with ITK_USE_SYSTEM*. But, it would work
>>> best if these projects were configured with CMake, create a
>>> <project>Config.cmake or <project>-config.cmake file, and use relative
>>> paths internally.
>>>
>>> HTH,
>>> Matt
>>>
>>> On Tue, May 10, 2016 at 5:25 PM, Rashad Kanavath
>>> <mohammedrashadkm at gmail.com> wrote:
>>> >
>>> >
>>> > On Tue, May 10, 2016 at 10:50 PM, D?enan Zuki? <dzenanz at gmail.com>
>>> wrote:
>>> >>
>>> >> Hi Rashad,
>>> >>
>>> >> a few months ago relative paths were completely removed from CMake,
>>> >> because they were never fully implemented. Have you followed
>>> recommendations
>>> >> from here for cross-compiling?
>>> >
>>> >
>>> > Yes. indeed. I had updated the mxe/src/itk.mk for several versions of
>>> ITK!
>>> >
>>> > Regarding relative path in cmake, I don't understand.  I didn't use
>>> cmake
>>> > specific REL_PATH.
>>> >>
>>> >>
>>> >> As for integrating your changes into ITK, you should submit a patch
>>> >> following the instructions here. If your changes don't break
>>> anything, they
>>> >> are likely to be integrated.
>>> >
>>> >
>>> > issue here is a bit different. For all libitk* stuff the story ends
>>> well.
>>> > For thirdparties, zlib, expat etc.. it is good idea to put the full
>>> path
>>> > because we don't know if they are in same install directory as ITK or
>>> not.
>>> > But this make the installed cmake modules non-portable even to a
>>> different
>>> > location on the same disk.
>>> >
>>> > Now if anyone want to provide a distributable setup of ITK. patch the
>>> > generated cmake files with sed and then copy it. This is what I am
>>> doing
>>> > right now!
>>> > A simple not perfect solution is to have all thirdparties make
>>> > <LIBRARY>_PREFIX variable inside the ITKConfig.cmake
>>> >
>>> > and for each library we use <LIBRARY>_PREFIX/include and
>>> > <LIBRARY>_PREFIX/lib
>>> >
>>> >
>>> > Another option is to avoid full path directly inside cmake module
>>> files and
>>> > put find_package() calls in the install tree.
>>> >
>>> > As these files are autogenerated by cmake, don't know what is possible.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >>
>>> >> Regards,
>>> >> D?enan
>>> >>
>>> >> On Mon, May 9, 2016 at 4:27 PM, Rashad Kanavath
>>> >> <mohammedrashadkm at gmail.com> wrote:
>>> >>>
>>> >>> Hello all,
>>> >>>
>>> >>> I have some issue when copying ITK install directory to a different
>>> >>> system. I agree this is not usual and may not appear on a linux
>>> distro or
>>> >>> windows.
>>> >>>
>>> >>> My requirement is bit different. I cross-compile ITK and then use the
>>> >>> binaries on Windows. Using dll and headers are fine. But the
>>> installed cmake
>>> >>> files are a problem. They have absolute path in
>>> ITK-4.8/Modules/*.cmake
>>> >>> files. It is not in all .cmake files even though I put a wildcard
>>> there..
>>> >>>
>>> >>> For a easy and quick workaround. I rely on mighty sed command to
>>> insert
>>> >>> something into installed cmake file.
>>> >>>
>>> >>> For example see this;
>>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>>> >>>
>>> >>> set(CMAKE_IMPORT_FILE_VERSION 1)
>>> >>> set(LIB_INSTALL_PREFIX)
>>> >>> get_filename_component(CURRENT_FILE_DIR "${CMAKE_CURRENT_LIST_FILE}"
>>> >>> PATH)
>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${CURRENT_FILE_DIR}"
>>> PATH)
>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>>> PATH)
>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>>> PATH)
>>> >>>
>>> >>> and at last:
>>> >>>
>>> >>> $(SED) -i 's,$(PREFIX)/$(TARGET),\${LIB_INSTALL_PREFIX},g'
>>> >>> 'lib/cmake/ITK-$(ITK_VER)/ITKTargets-release.cmake'
>>> >>>
>>> >>> I would like to have this patch inside the other .cmake files in the
>>> >>> installation and avoid the sed commands during post-installation
>>> >>>
>>> >>> Here is the list of cmake files that needs this change.
>>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>>> >>> lib/cmake/ITK-4.8/Modules/ITKZLIB.cmake
>>> >>> lib/cmake/ITK-4.8/Modules/ITKExpat.cmake
>>> >>> lib/cmake/ITK-4.8/Modules/ITKHDF5.cmake
>>> >>> lib/cmake/ITK-4.8/Modules/ITKJPEG.cmake
>>> >>> lib/cmake/ITK-4.8/Modules/ITKTIFF.cmake
>>> >>> lib/cmake/ITK-4.8/Modules/ITKPNG.cmake
>>> >>>
>>> >>> So is it possible to make the change into future version of ITK?
>>> >>>
>>> >>> The major issue here is those cmake files are generated by cmake. Is
>>> >>> there a way cmake could use relative path ?
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Regards,
>>> >>>    Rashad
>>> >>>
>>> >>> _______________________________________________
>>> >>> Powered by www.kitware.com
>>> >>>
>>> >>> Visit other Kitware open-source projects at
>>> >>> http://www.kitware.com/opensource/opensource.html
>>> >>>
>>> >>> Kitware offers ITK Training Courses, for more information visit:
>>> >>> http://kitware.com/products/protraining.php
>>> >>>
>>> >>> Please keep messages on-topic and check the ITK FAQ at:
>>> >>> http://www.itk.org/Wiki/ITK_FAQ
>>> >>>
>>> >>> Follow this link to subscribe/unsubscribe:
>>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> >    Rashad
>>> >
>>> > _______________________________________________
>>> > Powered by www.kitware.com
>>> >
>>> > Visit other Kitware open-source projects at
>>> > http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Kitware offers ITK Training Courses, for more information visit:
>>> > http://kitware.com/products/protraining.php
>>> >
>>> > Please keep messages on-topic and check the ITK FAQ at:
>>> > http://www.itk.org/Wiki/ITK_FAQ
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://public.kitware.com/mailman/listinfo/insight-developers
>>> >
>>>
>>
>>
>>
>> --
>> Regards,
>>    Rashad
>>
>
>


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161221/101c4546/attachment.html>

From matt.mccormick at kitware.com  Wed Dec 21 11:06:23 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 21 Dec 2016 11:06:23 -0500
Subject: [ITK-dev] installed ITK cannot be moved due to absolute path
In-Reply-To: <CANNqv9fFF4ukPPy8KSTDe+WWuCdqZDUz5=MLQN81V1Sf8j9Rpw@mail.gmail.com>
References: <CANNqv9eKZygjeSgdauFADK6jev2V9Q4Bhk8gfP=GkR5ngLfoGA@mail.gmail.com>
 <CAPf2UMTo6LY09u1gKxa+MPjOgyQjMh25ADHSdpv4wTc3GRzbZA@mail.gmail.com>
 <CANNqv9dC9F6PHSyrLfnqY2NbA8dSDxnD-kzEKTdUqwhW_Mea8A@mail.gmail.com>
 <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
 <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>
 <CAPf2UMRTmOMG9CON1w1X+-GUYzmcNGch5bu0dxq31_WVpT-O8g@mail.gmail.com>
 <CANNqv9fFF4ukPPy8KSTDe+WWuCdqZDUz5=MLQN81V1Sf8j9Rpw@mail.gmail.com>
Message-ID: <CALzTN-RDpB_gRY1L_fvFfyke2Jyhk=h2OAAMuy4hY1TJoy4KZQ@mail.gmail.com>

Hi Rashad,

The Find<Package>.cmake are purposely not provided because it is not
reliable and does not provide all the information required. The CMake
package configuration file allows ITK to declare what is required to
build it instead of requiring CMake to guess (and get it wrong).

For this case, it is recommended to turn off ITK_USE_SYSTEM_ZLIB,
which will make the ITK installation portable.

HTH,
Matt

On Wed, Dec 21, 2016 at 9:03 AM, Rashad Kanavath
<mohammedrashadkm at gmail.com> wrote:
> Hello D?enan,
>
> Thanks for your reply.  Unfortunately, this won't work in my case. I will
> try to explain it.
>
> I have installed itk in my system say: c:/projects/itk_install
>
> now I copy itk_install directory to another system of my colleague. If
> he/she is copying my "itk_install" folder into any directory other than
> c:/projects/, itk build is useless.
> cmake says it cannot find file c:/projects/itk_install/lib/ITKxxxxx.dll
> etc..
>
> This error is coming from
> c:/projects/itk_install/lib/cmake/ITK-4.10/ITKTargets-release.cmake. Note
> that this file is generated by cmake.
>
> So I have two options:
> 1. ask to copy "itk_install" directory to c:/projects/itk_install (easy, )
> 2. copy "itk_install" directory anywhere but search in
> <your-install-prefix>/lib/cmake/ITK-4.10 and replace all occurrence of
> c:/projects/itk_install with <your-install-prefix>
>
> Second solution is more awful compared to first. So for now, I insist on
> first option. But after a couple of such installation of "itk_install", it
> seems bad to me.
> Like I mentioned in last thread, technically my itk_install could be reused
> if cmake does not have absolute path in the install tree for ZLIB, fftw
> etc..
>
> FYI, there are other projects which does same thing and for them I have a
> custom Find<Package>.cmake in source tree. So don't care what ever they have
> in their lib/cmake/<Package> files
>
> If ITK devs can provide FindITK.cmake , then we could reuse that. Instead of
> ITKConfig.cmake stuff.
>
> Hope I explained case well. Let me know if you need any more information.
>
> Appreciate your help in solving this.
>
>
> On Tue, Dec 20, 2016 at 4:15 PM, D?enan Zuki? <dzenanz at gmail.com> wrote:
>>
>> Hi Rashad,
>>
>> one way to generate install tree in a different location is by changing
>> CMAKE_INSTALL_PREFIX in CMake, reconfiguring, regenerating project, the
>> building the INSTALL target. That should generate the install tree in your
>> desired location.
>>
>> Regards,
>> D?enan
>>
>> On Tue, Dec 20, 2016 at 4:48 AM, Rashad Kanavath
>> <mohammedrashadkm at gmail.com> wrote:
>>>
>>> Hello all,
>>>
>>> Is there a simple FindITK.cmake which can be used instead of config and
>>> targets cmake files?
>>>
>>> in my install tree, in ITKTargets-release.Cmake there exists absolute
>>> path for include and lib file.
>>>
>>> My install tree of ITK does not work on a different machine unless I copy
>>> them too exact same directory where I installed on machine.
>>>
>>> This goes against portability and it is cmake who is doing this work.
>>>
>>> Here is code in ITKTargets-release.cmake
>>>
>>> set_property(TARGET ITKMetaIO APPEND PROPERTY IMPORTED_CONFIGURATIONS
>>> RELEASE)
>>> set_target_properties(ITKMetaIO PROPERTIES
>>>   IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/ITKMetaIO-4.10.lib"
>>>   IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
>>> "C:/dashboard/otb/install_sb_x86/lib/zdll.lib;comctl32;wsock32"
>>>   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/ITKMetaIO-4.10.dll"
>>>   )
>>>
>>> see the absolute path to C:/dashboard/otb/install_sb_x86/lib/zdll.lib
>>>
>>> so if on a different machine no matter where I copy these cmake files for
>>> ITK, I must have zdll.lib in C:/dashboard/otb/install_sb_x86/lib/
>>> and same goes for fftw, expat etc.. if enabled.
>>>
>>> A simple find_package searching for for include and headers is portable
>>> than config files. Right now even copying the files on same compiler won't
>>> work.
>>> But in reality there is no technical issues.
>>>
>>> Is anyone aware of a better way other than manually updating those
>>> absolute path to zdll.lib
>>>
>>> On Tue, May 24, 2016 at 1:21 AM, Matt McCormick
>>> <matt.mccormick at kitware.com> wrote:
>>>>
>>>> Hi Rashad,
>>>>
>>>> It looks like MXE is configured to use system versions of EXPAT, HDF5,
>>>> JPEG, PNG, TIFF, and ZLIB:
>>>>
>>>>
>>>> https://github.com/mxe/mxe/blob/4135f9b1227ba56b92ceb8a982016370ad5c8894/src/itk.mk#L28-L33
>>>>
>>>> USE_SYSTEM could be disabled for these libraries.
>>>>
>>>> Or, it may be possible for the module system to learn relative
>>>> locations of these libraries with ITK_USE_SYSTEM*. But, it would work
>>>> best if these projects were configured with CMake, create a
>>>> <project>Config.cmake or <project>-config.cmake file, and use relative
>>>> paths internally.
>>>>
>>>> HTH,
>>>> Matt
>>>>
>>>> On Tue, May 10, 2016 at 5:25 PM, Rashad Kanavath
>>>> <mohammedrashadkm at gmail.com> wrote:
>>>> >
>>>> >
>>>> > On Tue, May 10, 2016 at 10:50 PM, D?enan Zuki? <dzenanz at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi Rashad,
>>>> >>
>>>> >> a few months ago relative paths were completely removed from CMake,
>>>> >> because they were never fully implemented. Have you followed
>>>> >> recommendations
>>>> >> from here for cross-compiling?
>>>> >
>>>> >
>>>> > Yes. indeed. I had updated the mxe/src/itk.mk for several versions of
>>>> > ITK!
>>>> >
>>>> > Regarding relative path in cmake, I don't understand.  I didn't use
>>>> > cmake
>>>> > specific REL_PATH.
>>>> >>
>>>> >>
>>>> >> As for integrating your changes into ITK, you should submit a patch
>>>> >> following the instructions here. If your changes don't break
>>>> >> anything, they
>>>> >> are likely to be integrated.
>>>> >
>>>> >
>>>> > issue here is a bit different. For all libitk* stuff the story ends
>>>> > well.
>>>> > For thirdparties, zlib, expat etc.. it is good idea to put the full
>>>> > path
>>>> > because we don't know if they are in same install directory as ITK or
>>>> > not.
>>>> > But this make the installed cmake modules non-portable even to a
>>>> > different
>>>> > location on the same disk.
>>>> >
>>>> > Now if anyone want to provide a distributable setup of ITK. patch the
>>>> > generated cmake files with sed and then copy it. This is what I am
>>>> > doing
>>>> > right now!
>>>> > A simple not perfect solution is to have all thirdparties make
>>>> > <LIBRARY>_PREFIX variable inside the ITKConfig.cmake
>>>> >
>>>> > and for each library we use <LIBRARY>_PREFIX/include and
>>>> > <LIBRARY>_PREFIX/lib
>>>> >
>>>> >
>>>> > Another option is to avoid full path directly inside cmake module
>>>> > files and
>>>> > put find_package() calls in the install tree.
>>>> >
>>>> > As these files are autogenerated by cmake, don't know what is
>>>> > possible.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >>
>>>> >> Regards,
>>>> >> D?enan
>>>> >>
>>>> >> On Mon, May 9, 2016 at 4:27 PM, Rashad Kanavath
>>>> >> <mohammedrashadkm at gmail.com> wrote:
>>>> >>>
>>>> >>> Hello all,
>>>> >>>
>>>> >>> I have some issue when copying ITK install directory to a different
>>>> >>> system. I agree this is not usual and may not appear on a linux
>>>> >>> distro or
>>>> >>> windows.
>>>> >>>
>>>> >>> My requirement is bit different. I cross-compile ITK and then use
>>>> >>> the
>>>> >>> binaries on Windows. Using dll and headers are fine. But the
>>>> >>> installed cmake
>>>> >>> files are a problem. They have absolute path in
>>>> >>> ITK-4.8/Modules/*.cmake
>>>> >>> files. It is not in all .cmake files even though I put a wildcard
>>>> >>> there..
>>>> >>>
>>>> >>> For a easy and quick workaround. I rely on mighty sed command to
>>>> >>> insert
>>>> >>> something into installed cmake file.
>>>> >>>
>>>> >>> For example see this;
>>>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>>>> >>>
>>>> >>> set(CMAKE_IMPORT_FILE_VERSION 1)
>>>> >>> set(LIB_INSTALL_PREFIX)
>>>> >>> get_filename_component(CURRENT_FILE_DIR "${CMAKE_CURRENT_LIST_FILE}"
>>>> >>> PATH)
>>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${CURRENT_FILE_DIR}"
>>>> >>> PATH)
>>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>>>> >>> PATH)
>>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>>>> >>> PATH)
>>>> >>>
>>>> >>> and at last:
>>>> >>>
>>>> >>> $(SED) -i 's,$(PREFIX)/$(TARGET),\${LIB_INSTALL_PREFIX},g'
>>>> >>> 'lib/cmake/ITK-$(ITK_VER)/ITKTargets-release.cmake'
>>>> >>>
>>>> >>> I would like to have this patch inside the other .cmake files in the
>>>> >>> installation and avoid the sed commands during post-installation
>>>> >>>
>>>> >>> Here is the list of cmake files that needs this change.
>>>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>>>> >>> lib/cmake/ITK-4.8/Modules/ITKZLIB.cmake
>>>> >>> lib/cmake/ITK-4.8/Modules/ITKExpat.cmake
>>>> >>> lib/cmake/ITK-4.8/Modules/ITKHDF5.cmake
>>>> >>> lib/cmake/ITK-4.8/Modules/ITKJPEG.cmake
>>>> >>> lib/cmake/ITK-4.8/Modules/ITKTIFF.cmake
>>>> >>> lib/cmake/ITK-4.8/Modules/ITKPNG.cmake
>>>> >>>
>>>> >>> So is it possible to make the change into future version of ITK?
>>>> >>>
>>>> >>> The major issue here is those cmake files are generated by cmake. Is
>>>> >>> there a way cmake could use relative path ?
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Regards,
>>>> >>>    Rashad
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Powered by www.kitware.com
>>>> >>>
>>>> >>> Visit other Kitware open-source projects at
>>>> >>> http://www.kitware.com/opensource/opensource.html
>>>> >>>
>>>> >>> Kitware offers ITK Training Courses, for more information visit:
>>>> >>> http://kitware.com/products/protraining.php
>>>> >>>
>>>> >>> Please keep messages on-topic and check the ITK FAQ at:
>>>> >>> http://www.itk.org/Wiki/ITK_FAQ
>>>> >>>
>>>> >>> Follow this link to subscribe/unsubscribe:
>>>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Regards,
>>>> >    Rashad
>>>> >
>>>> > _______________________________________________
>>>> > Powered by www.kitware.com
>>>> >
>>>> > Visit other Kitware open-source projects at
>>>> > http://www.kitware.com/opensource/opensource.html
>>>> >
>>>> > Kitware offers ITK Training Courses, for more information visit:
>>>> > http://kitware.com/products/protraining.php
>>>> >
>>>> > Please keep messages on-topic and check the ITK FAQ at:
>>>> > http://www.itk.org/Wiki/ITK_FAQ
>>>> >
>>>> > Follow this link to subscribe/unsubscribe:
>>>> > http://public.kitware.com/mailman/listinfo/insight-developers
>>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>    Rashad
>>
>>
>
>
>
> --
> Regards,
>    Rashad

From mohammedrashadkm at gmail.com  Wed Dec 21 12:05:54 2016
From: mohammedrashadkm at gmail.com (Rashad Kanavath)
Date: Wed, 21 Dec 2016 18:05:54 +0100
Subject: [ITK-dev] installed ITK cannot be moved due to absolute path
In-Reply-To: <CALzTN-RDpB_gRY1L_fvFfyke2Jyhk=h2OAAMuy4hY1TJoy4KZQ@mail.gmail.com>
References: <CANNqv9eKZygjeSgdauFADK6jev2V9Q4Bhk8gfP=GkR5ngLfoGA@mail.gmail.com>
 <CAPf2UMTo6LY09u1gKxa+MPjOgyQjMh25ADHSdpv4wTc3GRzbZA@mail.gmail.com>
 <CANNqv9dC9F6PHSyrLfnqY2NbA8dSDxnD-kzEKTdUqwhW_Mea8A@mail.gmail.com>
 <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
 <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>
 <CAPf2UMRTmOMG9CON1w1X+-GUYzmcNGch5bu0dxq31_WVpT-O8g@mail.gmail.com>
 <CANNqv9fFF4ukPPy8KSTDe+WWuCdqZDUz5=MLQN81V1Sf8j9Rpw@mail.gmail.com>
 <CALzTN-RDpB_gRY1L_fvFfyke2Jyhk=h2OAAMuy4hY1TJoy4KZQ@mail.gmail.com>
Message-ID: <CANNqv9d5WoUsaGwm8o56pU_o=gTp3wacVmbmg-jnncnz7TSrNA@mail.gmail.com>

On Wed, Dec 21, 2016 at 5:06 PM, Matt McCormick <matt.mccormick at kitware.com>
wrote:

> Hi Rashad,
>
> The Find<Package>.cmake are purposely not provided because it is not
> reliable and does not provide all the information required. The CMake
> package configuration file allows ITK to declare what is required to
> build it instead of requiring CMake to guess (and get it wrong).
>
> For this case, it is recommended to turn off ITK_USE_SYSTEM_ZLIB,
> which will make the ITK installation portable.
>

I need to use zlib, fftw and expat in that case from ITK build/

But I have also providing a different build of zlib for my other projects.

What are the missing information when using FindITK.cmake as opposed to itk
cmake configuration files?

I understand that saving absolute path of libraries which link with project
is easy to avoid any issues in linking or at runtime.
 And that is one type of solution and IMHO does not solve the problem.

Apart from that I would like to find out what are real issues with
Find<Package>.cmake



> HTH,
> Matt
>
> On Wed, Dec 21, 2016 at 9:03 AM, Rashad Kanavath
> <mohammedrashadkm at gmail.com> wrote:
> > Hello D?enan,
> >
> > Thanks for your reply.  Unfortunately, this won't work in my case. I will
> > try to explain it.
> >
> > I have installed itk in my system say: c:/projects/itk_install
> >
> > now I copy itk_install directory to another system of my colleague. If
> > he/she is copying my "itk_install" folder into any directory other than
> > c:/projects/, itk build is useless.
> > cmake says it cannot find file c:/projects/itk_install/lib/ITKxxxxx.dll
> > etc..
> >
> > This error is coming from
> > c:/projects/itk_install/lib/cmake/ITK-4.10/ITKTargets-release.cmake.
> Note
> > that this file is generated by cmake.
> >
> > So I have two options:
> > 1. ask to copy "itk_install" directory to c:/projects/itk_install (easy,
> )
> > 2. copy "itk_install" directory anywhere but search in
> > <your-install-prefix>/lib/cmake/ITK-4.10 and replace all occurrence of
> > c:/projects/itk_install with <your-install-prefix>
> >
> > Second solution is more awful compared to first. So for now, I insist on
> > first option. But after a couple of such installation of "itk_install",
> it
> > seems bad to me.
> > Like I mentioned in last thread, technically my itk_install could be
> reused
> > if cmake does not have absolute path in the install tree for ZLIB, fftw
> > etc..
> >
> > FYI, there are other projects which does same thing and for them I have a
> > custom Find<Package>.cmake in source tree. So don't care what ever they
> have
> > in their lib/cmake/<Package> files
> >
> > If ITK devs can provide FindITK.cmake , then we could reuse that.
> Instead of
> > ITKConfig.cmake stuff.
> >
> > Hope I explained case well. Let me know if you need any more information.
> >
> > Appreciate your help in solving this.
> >
> >
> > On Tue, Dec 20, 2016 at 4:15 PM, D?enan Zuki? <dzenanz at gmail.com> wrote:
> >>
> >> Hi Rashad,
> >>
> >> one way to generate install tree in a different location is by changing
> >> CMAKE_INSTALL_PREFIX in CMake, reconfiguring, regenerating project, the
> >> building the INSTALL target. That should generate the install tree in
> your
> >> desired location.
> >>
> >> Regards,
> >> D?enan
> >>
> >> On Tue, Dec 20, 2016 at 4:48 AM, Rashad Kanavath
> >> <mohammedrashadkm at gmail.com> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> Is there a simple FindITK.cmake which can be used instead of config and
> >>> targets cmake files?
> >>>
> >>> in my install tree, in ITKTargets-release.Cmake there exists absolute
> >>> path for include and lib file.
> >>>
> >>> My install tree of ITK does not work on a different machine unless I
> copy
> >>> them too exact same directory where I installed on machine.
> >>>
> >>> This goes against portability and it is cmake who is doing this work.
> >>>
> >>> Here is code in ITKTargets-release.cmake
> >>>
> >>> set_property(TARGET ITKMetaIO APPEND PROPERTY IMPORTED_CONFIGURATIONS
> >>> RELEASE)
> >>> set_target_properties(ITKMetaIO PROPERTIES
> >>>   IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/ITKMetaIO-4.10.lib"
> >>>   IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
> >>> "C:/dashboard/otb/install_sb_x86/lib/zdll.lib;comctl32;wsock32"
> >>>   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/ITKMetaIO-4.10.dll"
> >>>   )
> >>>
> >>> see the absolute path to C:/dashboard/otb/install_sb_x86/lib/zdll.lib
> >>>
> >>> so if on a different machine no matter where I copy these cmake files
> for
> >>> ITK, I must have zdll.lib in C:/dashboard/otb/install_sb_x86/lib/
> >>> and same goes for fftw, expat etc.. if enabled.
> >>>
> >>> A simple find_package searching for for include and headers is portable
> >>> than config files. Right now even copying the files on same compiler
> won't
> >>> work.
> >>> But in reality there is no technical issues.
> >>>
> >>> Is anyone aware of a better way other than manually updating those
> >>> absolute path to zdll.lib
> >>>
> >>> On Tue, May 24, 2016 at 1:21 AM, Matt McCormick
> >>> <matt.mccormick at kitware.com> wrote:
> >>>>
> >>>> Hi Rashad,
> >>>>
> >>>> It looks like MXE is configured to use system versions of EXPAT, HDF5,
> >>>> JPEG, PNG, TIFF, and ZLIB:
> >>>>
> >>>>
> >>>> https://github.com/mxe/mxe/blob/4135f9b1227ba56b92ceb8a9820163
> 70ad5c8894/src/itk.mk#L28-L33
> >>>>
> >>>> USE_SYSTEM could be disabled for these libraries.
> >>>>
> >>>> Or, it may be possible for the module system to learn relative
> >>>> locations of these libraries with ITK_USE_SYSTEM*. But, it would work
> >>>> best if these projects were configured with CMake, create a
> >>>> <project>Config.cmake or <project>-config.cmake file, and use relative
> >>>> paths internally.
> >>>>
> >>>> HTH,
> >>>> Matt
> >>>>
> >>>> On Tue, May 10, 2016 at 5:25 PM, Rashad Kanavath
> >>>> <mohammedrashadkm at gmail.com> wrote:
> >>>> >
> >>>> >
> >>>> > On Tue, May 10, 2016 at 10:50 PM, D?enan Zuki? <dzenanz at gmail.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> Hi Rashad,
> >>>> >>
> >>>> >> a few months ago relative paths were completely removed from CMake,
> >>>> >> because they were never fully implemented. Have you followed
> >>>> >> recommendations
> >>>> >> from here for cross-compiling?
> >>>> >
> >>>> >
> >>>> > Yes. indeed. I had updated the mxe/src/itk.mk for several versions
> of
> >>>> > ITK!
> >>>> >
> >>>> > Regarding relative path in cmake, I don't understand.  I didn't use
> >>>> > cmake
> >>>> > specific REL_PATH.
> >>>> >>
> >>>> >>
> >>>> >> As for integrating your changes into ITK, you should submit a patch
> >>>> >> following the instructions here. If your changes don't break
> >>>> >> anything, they
> >>>> >> are likely to be integrated.
> >>>> >
> >>>> >
> >>>> > issue here is a bit different. For all libitk* stuff the story ends
> >>>> > well.
> >>>> > For thirdparties, zlib, expat etc.. it is good idea to put the full
> >>>> > path
> >>>> > because we don't know if they are in same install directory as ITK
> or
> >>>> > not.
> >>>> > But this make the installed cmake modules non-portable even to a
> >>>> > different
> >>>> > location on the same disk.
> >>>> >
> >>>> > Now if anyone want to provide a distributable setup of ITK. patch
> the
> >>>> > generated cmake files with sed and then copy it. This is what I am
> >>>> > doing
> >>>> > right now!
> >>>> > A simple not perfect solution is to have all thirdparties make
> >>>> > <LIBRARY>_PREFIX variable inside the ITKConfig.cmake
> >>>> >
> >>>> > and for each library we use <LIBRARY>_PREFIX/include and
> >>>> > <LIBRARY>_PREFIX/lib
> >>>> >
> >>>> >
> >>>> > Another option is to avoid full path directly inside cmake module
> >>>> > files and
> >>>> > put find_package() calls in the install tree.
> >>>> >
> >>>> > As these files are autogenerated by cmake, don't know what is
> >>>> > possible.
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Regards,
> >>>> >> D?enan
> >>>> >>
> >>>> >> On Mon, May 9, 2016 at 4:27 PM, Rashad Kanavath
> >>>> >> <mohammedrashadkm at gmail.com> wrote:
> >>>> >>>
> >>>> >>> Hello all,
> >>>> >>>
> >>>> >>> I have some issue when copying ITK install directory to a
> different
> >>>> >>> system. I agree this is not usual and may not appear on a linux
> >>>> >>> distro or
> >>>> >>> windows.
> >>>> >>>
> >>>> >>> My requirement is bit different. I cross-compile ITK and then use
> >>>> >>> the
> >>>> >>> binaries on Windows. Using dll and headers are fine. But the
> >>>> >>> installed cmake
> >>>> >>> files are a problem. They have absolute path in
> >>>> >>> ITK-4.8/Modules/*.cmake
> >>>> >>> files. It is not in all .cmake files even though I put a wildcard
> >>>> >>> there..
> >>>> >>>
> >>>> >>> For a easy and quick workaround. I rely on mighty sed command to
> >>>> >>> insert
> >>>> >>> something into installed cmake file.
> >>>> >>>
> >>>> >>> For example see this;
> >>>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
> >>>> >>>
> >>>> >>> set(CMAKE_IMPORT_FILE_VERSION 1)
> >>>> >>> set(LIB_INSTALL_PREFIX)
> >>>> >>> get_filename_component(CURRENT_FILE_DIR
> "${CMAKE_CURRENT_LIST_FILE}"
> >>>> >>> PATH)
> >>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${CURRENT_FILE_DIR}"
> >>>> >>> PATH)
> >>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
> >>>> >>> PATH)
> >>>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
> >>>> >>> PATH)
> >>>> >>>
> >>>> >>> and at last:
> >>>> >>>
> >>>> >>> $(SED) -i 's,$(PREFIX)/$(TARGET),\${LIB_INSTALL_PREFIX},g'
> >>>> >>> 'lib/cmake/ITK-$(ITK_VER)/ITKTargets-release.cmake'
> >>>> >>>
> >>>> >>> I would like to have this patch inside the other .cmake files in
> the
> >>>> >>> installation and avoid the sed commands during post-installation
> >>>> >>>
> >>>> >>> Here is the list of cmake files that needs this change.
> >>>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
> >>>> >>> lib/cmake/ITK-4.8/Modules/ITKZLIB.cmake
> >>>> >>> lib/cmake/ITK-4.8/Modules/ITKExpat.cmake
> >>>> >>> lib/cmake/ITK-4.8/Modules/ITKHDF5.cmake
> >>>> >>> lib/cmake/ITK-4.8/Modules/ITKJPEG.cmake
> >>>> >>> lib/cmake/ITK-4.8/Modules/ITKTIFF.cmake
> >>>> >>> lib/cmake/ITK-4.8/Modules/ITKPNG.cmake
> >>>> >>>
> >>>> >>> So is it possible to make the change into future version of ITK?
> >>>> >>>
> >>>> >>> The major issue here is those cmake files are generated by cmake.
> Is
> >>>> >>> there a way cmake could use relative path ?
> >>>> >>>
> >>>> >>>
> >>>> >>> --
> >>>> >>> Regards,
> >>>> >>>    Rashad
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> Powered by www.kitware.com
> >>>> >>>
> >>>> >>> Visit other Kitware open-source projects at
> >>>> >>> http://www.kitware.com/opensource/opensource.html
> >>>> >>>
> >>>> >>> Kitware offers ITK Training Courses, for more information visit:
> >>>> >>> http://kitware.com/products/protraining.php
> >>>> >>>
> >>>> >>> Please keep messages on-topic and check the ITK FAQ at:
> >>>> >>> http://www.itk.org/Wiki/ITK_FAQ
> >>>> >>>
> >>>> >>> Follow this link to subscribe/unsubscribe:
> >>>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
> >>>> >>>
> >>>> >>
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Regards,
> >>>> >    Rashad
> >>>> >
> >>>> > _______________________________________________
> >>>> > Powered by www.kitware.com
> >>>> >
> >>>> > Visit other Kitware open-source projects at
> >>>> > http://www.kitware.com/opensource/opensource.html
> >>>> >
> >>>> > Kitware offers ITK Training Courses, for more information visit:
> >>>> > http://kitware.com/products/protraining.php
> >>>> >
> >>>> > Please keep messages on-topic and check the ITK FAQ at:
> >>>> > http://www.itk.org/Wiki/ITK_FAQ
> >>>> >
> >>>> > Follow this link to subscribe/unsubscribe:
> >>>> > http://public.kitware.com/mailman/listinfo/insight-developers
> >>>> >
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>>    Rashad
> >>
> >>
> >
> >
> >
> > --
> > Regards,
> >    Rashad
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161221/ce57e4e3/attachment.html>

From matt.mccormick at kitware.com  Wed Dec 21 19:07:03 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 21 Dec 2016 19:07:03 -0500
Subject: [ITK-dev] installed ITK cannot be moved due to absolute path
In-Reply-To: <CANNqv9d5WoUsaGwm8o56pU_o=gTp3wacVmbmg-jnncnz7TSrNA@mail.gmail.com>
References: <CANNqv9eKZygjeSgdauFADK6jev2V9Q4Bhk8gfP=GkR5ngLfoGA@mail.gmail.com>
 <CAPf2UMTo6LY09u1gKxa+MPjOgyQjMh25ADHSdpv4wTc3GRzbZA@mail.gmail.com>
 <CANNqv9dC9F6PHSyrLfnqY2NbA8dSDxnD-kzEKTdUqwhW_Mea8A@mail.gmail.com>
 <CALzTN-Q-Q9Ho4fmG99B4RUSwrpYCiihA3fiD_7WpKe5Kt24gtg@mail.gmail.com>
 <CANNqv9fSqBF0vdQQTa5An5xh8NPBd+cAuo=MvoR5UPDTr-cdOA@mail.gmail.com>
 <CAPf2UMRTmOMG9CON1w1X+-GUYzmcNGch5bu0dxq31_WVpT-O8g@mail.gmail.com>
 <CANNqv9fFF4ukPPy8KSTDe+WWuCdqZDUz5=MLQN81V1Sf8j9Rpw@mail.gmail.com>
 <CALzTN-RDpB_gRY1L_fvFfyke2Jyhk=h2OAAMuy4hY1TJoy4KZQ@mail.gmail.com>
 <CANNqv9d5WoUsaGwm8o56pU_o=gTp3wacVmbmg-jnncnz7TSrNA@mail.gmail.com>
Message-ID: <CALzTN-RChiSwPcs0f7r1Lpd4Myg_M7zM8f7DAA=TMSrNWecxOQ@mail.gmail.com>

On Wed, Dec 21, 2016 at 12:05 PM, Rashad Kanavath
<mohammedrashadkm at gmail.com> wrote:
>
>
> On Wed, Dec 21, 2016 at 5:06 PM, Matt McCormick <matt.mccormick at kitware.com>
> wrote:
>>
>> Hi Rashad,
>>
>> The Find<Package>.cmake are purposely not provided because it is not
>> reliable and does not provide all the information required. The CMake
>> package configuration file allows ITK to declare what is required to
>> build it instead of requiring CMake to guess (and get it wrong).
>>
>> For this case, it is recommended to turn off ITK_USE_SYSTEM_ZLIB,
>> which will make the ITK installation portable.
>
>
> I need to use zlib, fftw and expat in that case from ITK build/
>
> But I have also providing a different build of zlib for my other projects.

ITK's zlib will play nicely with the other zlibs -- it is name mangled.

Another path forward is to use a zlib that has a CMake package
configuration file and teach ITK to use that.


> What are the missing information when using FindITK.cmake as opposed to itk
> cmake configuration files?

ITK has required build flags, configuration options, and build include
directories, third party library requirements, linking library
requirements that depend on its modular configuration and differ based
on whether it is a build tree or an install tree. This would be
difficult if not impossible to try to recreate in a FindITK.cmake
module.


> I understand that saving absolute path of libraries which link with project
> is easy to avoid any issues in linking or at runtime.
>  And that is one type of solution and IMHO does not solve the problem.
>
> Apart from that I would like to find out what are real issues with
> Find<Package>.cmake

For example, if there are multiple zlib's on your system or if they
are installed in non-standard locations, the build system will be
lucky if it finds the one ITK was built against.

Another fundamental issue: for CMake to use a Find<Package>.cmake to
find <Package>, Find<Package>.cmake must exist and be used before
<Package> is found. That is, Find<Package>.cmake must be shipped with
CMake or a library that is trying to use <Package>. The version of
Find<Package>.cmake that comes with CMake or another library does not
necessarily correspond to the configuration required by the version of
<Package> that is available.

CMake Config-file modules should be used instead of Find-file modules
as a general best practice. The package can declare its build
requirements instead of making CMake try to guess them.

HTH,
Matt

From blowekamp at mail.nih.gov  Thu Dec 22 12:02:03 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Thu, 22 Dec 2016 17:02:03 +0000
Subject: [ITK-dev] ParameterScalesEstimator, EulerTransform and Randomness
Message-ID: <88501962-795D-4560-BC0F-9805B44E7F42@mail.nih.gov>

Hello,

After a recent change to ITK some random sampling is now being seeded by the wall clock instead of a fixed integer[1]. While one can globally set the seed to a fixed value. I am thinking it would be best to allow the user to control which components are ?fixed? random verses ?wall clock? random, to aid in reproducibility and what not.

In SimpleITK I have a test for the Optimizer?s scales estimator that began failing to my surprise[1] with the ITK updated locally. I expected some registration related to random sampling of the virtual domain to change but I was surprised about the Optimizer?s scales. So what is interesting:

1) The Euler2DTransform is not being classified as an Affine transform by the parameter estimator.
2) The random sampling strategy is used for the parameter scale estimator.
3) There is no way to set the specific seed used for this random image iteration. The further oddity is that the ImageRandomIterators use a global singleton, so if you did set a seed for the iterator, it modified the global singleton, there by having global side effects.

The parameters estimator is an interesting case for ?wall clock? randomness. The small differences in the parameter scales due to randomness get amplified over the optimization process of registration.

What to do? How can we provide control of the scales estimator?s randomness?

Thanks,
Brad





[1] https://github.com/InsightSoftwareConsortium/ITK/commit/4e6c5bd69a8c24181fee18901ea232084f6ab785
[2] https://github.com/SimpleITK/SimpleITK/blob/69bb27bde3250a0db591bfa111a5bd2f44de0ef5/Testing/Unit/sitkImageRegistrationMethodTests.cxx#L844-L873
[3] https://github.com/InsightSoftwareConsortium/ITK/blob/6b8108dd6a05cd32dee20e5f1fd29e47d7f31a77/Modules/Numerics/Optimizersv4/include/itkRegistrationParameterScalesEstimator.hxx#L397
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161222/b1a0a9a7/attachment.html>

From isaiah.norton at gmail.com  Thu Dec 22 12:55:03 2016
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Thu, 22 Dec 2016 12:55:03 -0500
Subject: [ITK-dev] ITK+static+wrapping [ref: 21857 "Enable singleton
	program global timestamp"]
In-Reply-To: <CALzTN-Q_RpKMEekQ-cgzHQaF8eV7R_VpE+QaNKxn-d-9t0ZuGw@mail.gmail.com>
References: <CADFtqoq+0kvvBPKKOCL9Tz_hPbjC8=uD6vY7DAK5JsOnwLiymA@mail.gmail.com>
 <CALzTN-Q_RpKMEekQ-cgzHQaF8eV7R_VpE+QaNKxn-d-9t0ZuGw@mail.gmail.com>
Message-ID: <CADFtqootJKmcY3fGb2WDk9VU+5D3RZnfBHXVShNuU0guZMG60g@mail.gmail.com>

Hi Matt,

There is one potential technical issue with the scheme added by 21857. I
think that users who embed Python in a native application, with the app
statically linked to ITK, will need to manually ensure that the
application-side timestamp is initialized to point to the variable from
_ITKCommonPython. Otherwise, any objects initialized from application-side
ITK code would face the same desynchronization issue. Also, as mentioned in
the comments on the merge request, fully supporting the
(ITK_WRAP_PYTHON=ON, BUILD_SHARED_LIBS=OFF) multi-object configuration will
require moving other globals to the new Python side-loaded singleton system.

Given the above, perhaps that build configuration should be an error by
default, for now (with override available), so people don't use it
inadvertently? The problems caused can be difficult to debug.

Best,
Isaiah


On Sat, Dec 17, 2016 at 10:41 AM, Matt McCormick <matt.mccormick at kitware.com
> wrote:

> Hi Isaiah,
>
> Here is some more information and background.
>
>
> > What is the rationale behind creating so many separate, statically-linked
> > Python modules? (78 `_ITK*Python.so` files on my machine). Creating a
> single
> > bundle instead should resolve the original issue, and might also reduce
> the
> > size of the final library [3].
>
> For background, the GlobalTimeStamp, is a very important variable in
> ITK (and VTK). This is an atomic integer that gets incremented when
> any itk::Object (most classes in ITK) is "Modified", i.e. changed to
> note that it should be updated in a processing pipeline. So, almost
> all ITK-based code needs it, and it needs to be global across the
> entire program.
>
> The GlobalTimeStamp lives in and is used my itk::TimeStamp.cxx, and it
> is incremented on every call to ::Modified(). The itk::TimeStamp class
> is linked into libITKCommon.
>
> When ITK is built with shared libraries, libITKCommon is shared, and
> everything shares the GlobalTimeStamp. When ITK is built with static
> libraries, every binary that links in libITKCommon will get its own
> GlobalTimeStamp.
>
> Unfortunately, a shared libITKCommon is not always possible. For the
> official Python packaging format, wheels, native libraries are not yet
> officially supported [1].
>
> The advantages of not linking everything into one, giant, monolithic
> `_ITK*Python.so` are that 1) we can lazily load only the parts of the
> library that we need, and 2) the brilliant ITK community members can
> extend ITK to create their own ITK Python module. For example, see the
> awesome ITKMinimalPathExtraction [2] or ITKIsotropicWavelets [3]
> modules.
>
> While I also investigated, for example, using CMake object libraries
> to make itk::TimeStamp an exported symbol in _ITKCommonPython.so and
> only linked there [4], this is a more complex build configuration.
> Additionally, according to the Python documentation, exporting extra
> symbols in a CPython extension module is officially not supported [5].
> In practice, I have found that extra symbols can segfault the process
> on module import with Python 3.5 on Windows. So, the sharing is done
> the officially supported way, via PyCapsule.
>
>
> > Additionally, I am wondering if cross-module `dynamic_cast` works
> correctly
> > in the current situation -- because the typeinfos in each static module
> .so
> > have different addresses [4]. (I'm not sure how to create a situation to
> > test this from Python)
>
> Yes, since the Python wrapping covers the entire toolkit, it is an
> excellent stress test for the dynamic_cast issue. When we developed
> the dynamic_cast patch, we used Python wrapping with static libraries
> and experimentally enabled hidden symbols by default [6]. Without the
> dynamic_cast fix, the Python tests failed, and with the fix, they
> pass. It turns out that we missed some mark-up on a few classes as
> indicated by warnings in the Python wrapping and non-wrapping test
> failures, but we are working on resolving those now.
>
> Thanks,
> Matt
>
>
> [1] https://mail.python.org/pipermail/wheel-builders/2016-April/
> 000090.html
>
> [2] https://github.com/InsightSoftwareConsortium/ITKMinimalPathExtraction
>
> [3] https://github.com/phcerdan/ITKIsotropicWavelets
>
> [4] https://github.com/thewtex/ITK/commits/thewtex-PythonModifiedTime55
>
> [5] https://docs.python.org/3.5/extending/extending.html#providi
> ng-a-c-api-for-an-extension-module
>
> [6] http://review.source.kitware.com/#/c/21766/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161222/e126f657/attachment.html>