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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
