Date: Sat, 3 Dec 2016 00:00:01 +0800 From: Julian Elischer <julian@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r309035 - in head/lib/libpathconv: . tests Message-ID: <4de52b2a-fef9-f043-2409-c77bafc599fe@freebsd.org> In-Reply-To: <20161127204305.GA58954@stack.nl> References: <201611230757.uAN7vqmC008888@repo.freebsd.org> <20161127204305.GA58954@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28/11/2016 4:43 AM, Jilles Tjoelker wrote: > On Wed, Nov 23, 2016 at 07:57:52AM +0000, Julian Elischer wrote: >> Author: julian >> Date: Wed Nov 23 07:57:52 2016 >> New Revision: 309035 >> URL: https://svnweb.freebsd.org/changeset/base/309035 >> Log: >> This little BSD licensed library has been kicking around for years. >> It allows one to trivially convert an absolute path to a relative path >> and the reverse. The test programs themselves are very useful in scripts >> but the real use comes shortly with the -r and -a arguments to ln. >> These are sometimes known as the --relative and --absolute flags and >> can force a symlink to be relative when you only have an absolue path. >> Another place these are sometimes used is to add -a and -r args to 'realpath'. >> Incredibly useful in Makefiles. >> I was going to just add the files in with 'ln' but a library makes more sense. >> The test programs may come out in their own right some day for scripting. >> released under a BSD 2-clause: >> * Copyright (c) 1997 Shigio Yamaguchi. All rights reserved. >> * Copyright (c) 1999 Tama Communications Corporation. All rights reserved. >> The test directry does not conform to any framework. >> Not connected to build. >> doc people may want to play with the manual pages. >> Obtained from: https://www.tamacom.com/pathconvert.html Shigio Yamaguchi. >> MFC after: 1 month >> Relnotes: yes >> Sponsored by: Panzura, Tama Communications Corporation > Consider making this a static-only library or a part of an existing > library such as libc or libutil, since the overhead of a shared object > is rather big compared to the amount of code here. yeah I was thinking of making it part of libc but libc is already such a kitchen sink and there are only two planned users. ln and realpath. A static library is one idea for sure. (or even just a .o). The actual real target for this is the build itself. Currently we are making lots of symlinks that should be relative but we only really have absolute information. This allows symlink -sr to dynamically generate the correct relative symlink, given absolute args. e.g. /usr/lib/libm.so -> /lib/libm.so.5 should really be ../../lib/libm.so.5 so that when it is read from outside a jail it still refers to the right place. I'm waiting for a gap in my work schedule to get ln and realpath changes in place. > > Thanks for not linking this to the build right away. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4de52b2a-fef9-f043-2409-c77bafc599fe>