[Insight-developers] [Insight-users] 50 character limit in ITK on Win32?

Thu May 3 18:18:14 EDT 2012

Hi David,

I am locally removing the check for now.  My concern was that I'm
developing a deployment script where, rather than having to check
binaries into source control, the script will sync to the itk repo, to
a particular commit, and then build that commit, starting from scratch
and checking the appropriate cmake options.  I just want to avoid
having to remove the check in the script, since it seems superfluous
to my build process anyway.

I'd also suggest that there be a maximum character file name style
convention along with all of the other style requirements that ITK
has.  I don't think Windows' 255 character path limit is going away
any time soon, and in light of that, using file names like
ConstNeighborhoodIteratorGetBoundaryConditionChange.xml
and
itkLevelSetEvolutionNumberOfIterationsStoppingCriterionTest.cxx
would invite this kind of problem, especially if the files are buried
deep into several nested directories.

I'll look out for CMake 2.8.9 and update to it once it's out.

Thanks,
Mark

On Thu, May 3, 2012 at 3:04 PM, David Cole <david.cole at kitware.com> wrote:
> On Thu, May 3, 2012 at 5:30 PM, Mark Roden <mmroden at gmail.com> wrote:
>> Hi Cory,
>>
>> OK, I'll switch over to the developer's thread.
>>
>> But it appears that the 50 character limit (or 51 character limit, as
>> reported by Alex Gouaillard) is only a problem with a particular
>> combination of vs2010 and cmake 2.8.3.  For those of us with vs2008,
>> it's just fine to have a 66 character (or longer) path.
>>
>> I would propose, then, that this error message not be for any and all
>> versions of win32, but only for those compiler/cmake combinations
>> where this bug exists.  Otherwise, this limit is just overly
>> restrictive.
>>
>> Thanks,
>> Mark
>>
>> On Thu, May 3, 2012 at 2:24 PM, Cory Quammen <cquammen at cs.unc.edu> wrote:
>>> Mark,
>>>
>>> I think the path length choice was made conservatively because no one
>>> had the patience to figure out the exact length where things go wrong.
>>>
>>> The depth of the source tree, especially with the third-party
>>> libraries, is more of a problem that are the file name lengths in ITK.
>>>
>>> It might be more reasonable to issue a warning rather than halt with
>>> an error. You may want to propose this to the developers list to see
>>> what others think.
>>>
>>> - Cory
>>>
>>> On Thu, May 3, 2012 at 5:13 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>> But a path length of 66 works.
>>>>
>>>> It appears that this patch was for a particular compiler (vs2010) and
>>>> a particular version of cmake (2.8.3).  That's a much more specific
>>>> issue than all win32 platforms; I'm on vs2008, and as I said, 66
>>>> characters works just fine.
>>>>
>>>> And I would be strongly in favor of making this a warning, rather than
>>>> hard limit, if it's difficult/impossible to detect that particular
>>>> combination of compiler/cmake versions.  I don't, and never have had,
>>>> an issue building in ITK in any random directory, regardless of path
>>>> length-- maybe because I tend to keep my path lengths lower than 100
>>>> characters.
>>>>
>>>> But if this does continue to be an issue, is there some kind of style
>>>> guide for path length?  I see some really absurdly long filenames in
>>>> there, and if it really is an issue with vs2010, then maybe that style
>>>> should be enforced (along with all of the other commit rules).
>>>>
>>>> On Thu, May 3, 2012 at 2:04 PM, Cory Quammen <cquammen at cs.unc.edu> wrote:
>>>>> Mark,
>>>>>
>>>>> The limit is there to save your sanity :-)
>>>>>
>>>>> Did you try to compile with a path length of 100 characters? When I
>>>>> did, I ran into a file-not-found complaint by the compiler when
>>>>> compiling GDCM. Then I checked to see that the file it is complaining
>>>>> about does indeed exist.
>>>>>
>>>>> See the long email thread that led to this restriction here:
>>>>>
>>>>> http://www.itk.org/pipermail/insight-developers/2011-June/019268.html
>>>>>
>>>>> Basically, the relative paths generated by CMake and limitations in
>>>>> the length of paths in Visual Studio lead to this limit.
>>>>>
>>>>> Cory
>>>>>
>>>>> On Thu, May 3, 2012 at 4:49 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I've just recompiled itk 4.0, and found that there's a 50 character
>>>>>> path limit for win32.
>>>>>>
>>>>>> What's the logic behind this?  I comment out that line, and everything
>>>>>> works perfectly fine.
>>>>>>
>>>>>> The filename limit for windows is 255 (260 including the drive letter
>>>>>> and trailing null), but each component of the path can be 255
>>>>>> characters long.  MacOS has the same limit for HFS+, where each
>>>>>> element is locked to 255, but the total path has to be 1024 or lower.
>>>>>> (source: http://en.wikipedia.org/wiki/Comparison_of_file_systems).  If
>>>>>> you're not using windows-specific programming, but just treating the
>>>>>> path as a string, there's a 255 character limit.
>>>>>>
>>>>>> With my base file path that's 66 characters long, the longest filename
>>>>>> I can find is 146:
>>>>>>
>>>>>> C:\Users\mmroden\Documents\src\MyProjectsinQT\ExternalLibs\itk\ITK\Documentation\Migration\ConstNeighborhoodIteratorGetBoundaryConditionChange.xml
>>>>>>
>>>>>> That's a far cry from 255.
>>>>>>
>>>>>> Just how deep are the paths in ITK anyway?  Is the directory tree
>>>>>> really 205 characters long?  Or is this just someone guessing without
>>>>>> actually checking?
>>>>>>
>>>>>> The problem with this is that I want to incorporate ITK building as
>>>>>> part of a build script, rather than having to checkin binary images
>>>>>> into a repo.  I'd have to add a portion to the script to remove the
>>>>>> limit.
>>>>>>
>>>>>> What if it were just set to 100?
>>>>>>
>>>>>> Thanks,
>>>>>> Mark
>>>>>> _____________________________________
>>>>>> 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://www.itk.org/mailman/listinfo/insight-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cory Quammen
>>>>> Research Associate
>>>>> Department of Computer Science
>>>>> The University of North Carolina at Chapel Hill
>>>
>>>
>>>
>>> --
>>> Cory Quammen
>>> Research Associate
>>> Department of Computer Science
>>> The University of North Carolina at Chapel Hill
>> _______________________________________________
>> 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://www.itk.org/mailman/listinfo/insight-developers
>
>
> This commit that Brad King made recently in CMake (and it will appear
> in the 2.8.9 release in a couple months) does exactly that: it warns
> when it encounters a path that's too long, and only on Visual Studio
> 10.
>
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ce9fe0c26cfddb766901cfd1ccbc9def71c7
>
> I'd strongly, strongly encourage you to keep your Windows root path
> for ITK source and build trees to be as short as possible anyhow.
>
> So, after CMake 2.8.9 is required (or at least detected) we can modify
> the ITK CMakeLists to eliminate / conditionalize that chunk.
>
> We could turn it into a warning.... but would people pay attention and
> move things when they hit it, or would they plow through, and then hit
> a much later build error and then be mad that they wasted their time?
>
> You can certainly make it a warning, make it conditional on VS10, or
> just eliminate it locally.
>
>
> David