[Insight-developers] Fwd: Change in ITK[master]: COMP: root of source and binary dir of ITK should not be too...

[David Cole]

The point of the change is to notify first-time people that the build is not
going to work an hour from now when the build gets to a certain point, so
move the source/binary tree now.

The error string is very clear and says exactly how to solve "the problem."

Other recommendations are welcome.

Leaving it at "no limit" and letting people hit hard-to-diagnose problems
later on is not an option. If it's going to fail, then force it to fail
early on and give clear instructions on how to deal with it.



On Thu, Jun 23, 2011 at 3:23 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> But, we should not break compiles that already work. Seems to be a
> challenge to find the proper limit.
>
> On Thu, Jun 23, 2011 at 3:14 PM, David Cole <david.cole at kitware.com>
> wrote:
> > On Thu, Jun 23, 2011 at 2:18 PM, Bradley Lowekamp <
> blowekamp at mail.nih.gov>
> > wrote:
> >>
> >> On locked down PCs ( corporate or government ) some people can't change
> >> files out side of their home directory.
> >
> > These folks will have to choose a short path within their home directory.
> > That should be do-able...
> >
> >>
> >> As far as I know windows also requires you to be an administer to be
> able
> >> to run/compile with visual studio. But perhaps this will change in the
> >> future?
> >
> > It does *not* require administrator privileges for use with CMake and C++
> > code. If you are doing web development, database development, or COM
> > development and need to write reg keys, then you may need admin
> privileges
> > to do some certain build tasks, but C++ compiling should be good for
> > non-admins.
> >
> >>
> >> I thought this was a bug in VS2010 and cmake 2.8.4 that was patched.
> That
> >> is it should be using shorter relative paths for some of these things.
> >
> > We made a change to CMake to try to workaround the problem, but just this
> > week we've discovered another (worse) problem *caused* by that change...
> So
> > it looks like we're going to have to revert that change for the final
> > release of 2.8.5.
> > So the problem will re-appear after we revert that change.
> > Which is one of the reasons I'm in favor of this patch.
> >
> > David
> >
> >>
> >>
> >> Brad
> >>
> >> On Jun 23, 2011, at 2:13 PM, David Cole wrote:
> >>
> >> This gerrit change proposes to limit the path length of both the source
> >> and binary trees on Windows builds of ITK. Before we accept this change,
> is
> >> there anybody who has a reason why this would be a problem for them?
> >> I think it's a reasonable compromise given the length of the depth of
> the
> >> tree, and the problems that ensue. (When using certain versions of CMake
> and
> >> certain versions of Visual Studio, relative path names combined with the
> >> absolute path of the build tree, combine to exceed the 250-something
> >> character file name limit in some of the underlying Windows tools
> used...)
> >> Raise objections now, if any, or forever hold your peace. :-)
> >>
> >> Thanks,
> >> David C.
> >>
> >> ---------- Forwarded message ----------
> >> From: Code Review <review at kitware.com>
> >> Date: Thu, Jun 23, 2011 at 12:07 PM
> >> Subject: Change in ITK[master]: COMP: root of source and binary dir of
> ITK
> >> should not be too...
> >> To: David Cole <david.cole at kitware.com>
> >>
> >>
> >> From Alex. Gouaillard <agouaillard at gmail.com>:
> >>
> >> Hello David Cole,
> >>
> >> I'd like you to do a code review.  Please visit
> >>
> >>    http://review.source.kitware.com/1967
> >>
> >> to review the following change.
> >>
> >> Change subject: COMP: root of source and binary dir of ITK should not be
> >> too deep.
> >> ......................................................................
> >>
> >> COMP: root of source and binary dir of ITK should not be too deep.
> >>
> >> Change-Id: I79013671626f70b869e5d4e11a7e1d8987dad2b9
> >> ---
> >> M CMakeLists.txt
> >> 1 file changed, 23 insertions(+), 0 deletions(-)
> >>
> >>
> >>  git pull ssh://review.source.kitware.com/ITK refs/changes/67/1967/1
> >> --
> >> To view, visit http://review.source.kitware.com/1967
> >> To unsubscribe, visit http://review.source.kitware.com/settings
> >>
> >> Gerrit-MessageType: newchange
> >> Gerrit-Change-Id: I79013671626f70b869e5d4e11a7e1d8987dad2b9
> >> Gerrit-PatchSet: 1
> >> Gerrit-Project: ITK
> >> Gerrit-Branch: master
> >> Gerrit-Owner: Alex. Gouaillard <agouaillard at gmail.com>
> >> Gerrit-Reviewer: David Cole <david.cole at kitware.com>
> >>
> >> _______________________________________________
> >> 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.html
> >>
> >> 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://www.itk.org/mailman/listinfo/insight-developers
> >>
> >> ========================================================
> >>
> >> Bradley Lowekamp
> >>
> >> Lockheed Martin Contractor for
> >>
> >> Office of High Performance Computing and Communications
> >>
> >> National Library of Medicine
> >>
> >> blowekamp at mail.nih.gov
> >>
> >
> >
> > _______________________________________________
> > 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.html
> >
> > 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://www.itk.org/mailman/listinfo/insight-developers
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110623/c11d79f6/attachment.htm>