[Insight-developers] Adding std::tr1 to ITK?

[Tom Vercauteren]

Thanks for the feedback. It make a little more sense to me now but I
still have some questions...

On Wed, Nov 10, 2010 at 17:36, Brad King <brad.king at kitware.com> wrote:
> On 11/10/2010 10:50 AM, Tom Vercauteren wrote:
>> On Wed, Nov 10, 2010 at 16:36, Brad King <brad.king at kitware.com> wrote:
>>> Copying Boost headers into ITK will cause future problems for those
>>> that try to build applications involving both ITK and Boost.  One
>>> goal of the ITK Modularization effort is to be able to depend on
>>> Boost as a 3rd-party library *without* copying it into ITK/Utilities.
>>> That will allow applications to use both libraries cleanly.
>>
>> Indeed, I was not proposing to copy the headers into the ITK
>> repository. I think we should however try to make the process as easy
>> as possible. That is, we should try not to require the users to
>> install boost if they don't already have it.
>
> This should be the job of the modularization / packaging infrastructure
> used to build ITK modules.  Ideally boost will be made available before
> CMake even starts running on ITK.

Would indeed be nice. Any plans on how to make this available? The
only documentation about the modularization I saw are on the wiki:
  http://itk.org/Wiki/ITK_Release_4/Modularization
and none discuss third party dependencies.


>> Could something like that be done with the ExternalProject_Add command
>> from cmake? I was thinking of the following pseudo code:
>>
>> if not system has tr1
>>   if not found local boost install
>
> There is no distinction between "system" and "local install".  Both are
> outside of our build.

What I meant by system is actually the compiler which may come with
its own native TR1 implementation (i.e. not from boost). What I meant
by local is any boost implementation be it in from a package manager
or a manual install.


>>     fetch and configure boost tr1 using cmake ExternalProject_Add and maybe bcp
>
> One problem with this approach is that the headers and libraries will
> not even exist while CMake is configuring ITK.  CMake will not be able
> to generate link rules to bring in the libraries by full path unless
> we memorize where ExternalProject_Add will put them on every platform.

Since I haven't tried ExternalProject_Add yet I might have
misunderstood it... see below for a clarification of my proposal.


> Generally the ExternalProject module is useful for "superbuilds" where
> the only code depending on the output of an external project build is
> in another external project build.
>
> This is why we have traditionally used the Utilities/$dep approach with
> an ITK_USE_SYSTEM_$dep option.  Each dependency is either provided ahead
> of time or built as part of the project.  In both cases the library
> file locations are known to the targets that depend on them.

What I meant was something very close to what we already have with
ITK_USE_SYSTEM_$dep. The main difference being that we don't include
boost TR1 code into the ITK repository. Let me try to a new version
the pseudo cmake code:

if not compiler has native TR1 implementation
  if ITK_USE_SYSTEM_BOOST_TR1
    add SYSTEM_BOOST_TR1 include paths to ITK
  else
    download boost TR1 headers into Utilities/BoostTR1
    add Utilities/BoostTR1 include paths to ITK
  end
end

I guess that for the specific case of boost TR1, things are made a bit
easier since it appears to be a headers only library
  http://www.boost.org/doc/libs/

In this case, the targets that depend on TR1 know where the headers are.


Kent: Another comment below

On Wed, Nov 10, 2010 at 17:59, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> Boost's tr1 could be fetched as an external project and integrated.  The
> namespace in boost is std::tr1 which looks just like any 'native' tr1
> implementation.

This is in line with what I imagined.


> What I don't know is if you can just pull down the TR1 stuff from boost by
> itself.

This is the purpose of the bcp tool that comes with boost. Now that I
think about it, my proposal above might be difficult to implement
since it may require the use of bcp which might not be available
directly....

>  Boost is huge though, and what I'd like to avoid is TR1 being the
> camel's nose getting into the tent.

Agreed, sticking to TR1 and not allowing the use of other parts of
boost seems to be the most reasonable option has TR1 will eventually
become part of the c++ standard.

Tom