repetitive path gives filename too long errors

[René J.V. Bertin]

On Monday March 09 2015 10:28:36 Mojca Miklavec wrote:

>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/

Yep...

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

Heh. Historical reasons that made me create a partition called Debian (and one called Win) that was case-sensitive (UFS initially...) and that partly because of that became my work partition. Lots of symlinks and muscle memory made the name stick.
My /p^Ho^Ht^H^H/opt/local is a symlink to /Volumes/Debian/MP9 (MacPorts 10.9) . OS X's habit of resolving symlinks means you get to see the naked truth in my logs (and of course that habit doesn't help keeping MacPorts path short either).

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

What happens when you set workpath to something short like /tmp/mp ?

Heh, if all else fails I can always cook up a script that the user can execute outside of MacPorts, setting up a build directory under /tmp, doing the build and then the install into ${destroot}. I'd just need a little message dialog with a button to press when the port file processing can go on :)

R.