bug reported by Matt Clarkson ("Too Long Path for shell"):
current behaviour: the superbuild creates very large make commands with a lot of duplicated include directories. on some machines the build process fails
desired behaviour: remove all duplicates from the include directories
current workaround: on machines with a failing build the path to the MITK binary directory should be shortened as much as possible
This appeared to help:
https://github.com/NifTK/MITK/commit/c92d85a2817c5b6dffcbc457e198f152d8743938
(at least on my first Linux build). I guess it should work on Windows, Mac, but haven't test it yet.
M
I just today saw your commit, which probably is the "right" solution.
The current MITK master contains commit 49e86257b095ca6b69591605a2e3f99987440f3c which basically introduced the same changes and is related to T15885.
Is that okay for you or do you need a feature branch based on the latest release flag?
That should work for me.
(I will add Miklos as cc'd).
Basically, we are currently doing our ITKv4 upgrade work. So, our niftk branch on our Github fork of MITK is up to an including your MITK-2013.06 release, plus a few of our bugfixes or internal changes.
Once this is done, I will try to update to the very latest MITK. This will require new Boost, GDCM and OpenCV, but basically, we will copy your external project CMake stuff to compile in a very similar fashion.
I will also do an 'audit' to do a line by line diff of our NifTK/MITK/niftk branch with the MITK/master branch, with the intention of minimising the number of lines of code changed. So, relatively shortly, we will have an audit of what exactly are the differences. I think it should be <= 5 features, so nothing hugely significant.
Then, with regards to T15885, all the Utilities becoming external is fine. My only question is will the libraries and API be available? i.e. if I wanted to use Qxt, then is it 'accessible'? Or is it hidden? Currently we have no stuff that depends on these, other than implicitly due to our dependence on MITK modules.
Regards.
Matt
(In reply to Matt Clarkson from comment #3)
... I think it should be <= 5
features, so nothing hugely significant.
Sounds good!
Then, with regards to T15885, all the Utilities becoming external is
fine. My only question is will the libraries and API be available? i.e. if I
wanted to use Qxt, then is it 'accessible'? Or is it hidden? Currently we
have no stuff that depends on these, other than implicitly due to our
dependence on MITK modules.
Everything is accessible. Adding a "PACKAGE_DEPENDS Qxt" to the MITK_CREATE_MODULE macro explicitly creates a dependency and sets up include and linker information.