repetitive path gives filename too long errors

[Mojca Miklavec]

On Mon, Mar 9, 2015 at 10:08 AM, René J.V. wrote:
> On Sunday March 08 2015 23:25:53 Ryan Schmidt wrote:
>
>>
>>I agree, those filenames are too long. Whatever is creating those long filenames should rethink that strategy. I don't know what's creating those filenames, only that it's not MacPorts.
>
> I CC'ed here mostly to see if any port maintainers had run into a similar issue and found a workaround. The repetition isn't MacPorts fault, but the length of the repeated component is (as far as that's a fault).

I didn't run into exactly this problem, but into something else that's
related to "too long" paths and only manifests itself on Lion's
default clang compiler (clang-425.0.28; based on LLVM 3.2svn) when
linking against libc++. Taking a newer compiler (or making the paths
shorter) solves the problem.

http://www.cmake.org/Bug/view.php?id=15039
http://trac.macports.org/ticket/44129


It's probably a tiny bit of everyone's fault. MacPorts also generates
potentially insanely long folder names. It starts with things like
    _opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_subversion-perlbindings
inside /opt/local/var/macports/build/, but the file name can get
arbitrary long if I set up a local repository in
    /Users/me/some/very/very/very/very/very/very/very/very/.../very/long/path/

One thing that's not clear to me is how you ended up with "Debian" and
"ports" mixed together in the same filename.

I don't have experience with ninja, so I don't know how their build
system works, but if everyone behaves a tiny bit like MacPorts does in
the example above (and assumes that others will use sane and short
paths), it's easy to exceed the maximum filename length. But it would
certainly make sense to find out what tool contributes to what part of
the path and try to fix that.

I certainly agree that at some point it might make sense to allow
building ports in some path with a very short prefix.

Mojca