On 5/3/17 11:20 pm, Baptiste Daroussin wrote:
On Sun, Mar 05, 2017 at 11:11:35PM +0800, Julian Elischer wrote:
On 5/3/17 9:19 pm, Rodney W. Grimes wrote:
-- Start of PGP signed section.
On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote:
Author: rgrimes
Date: Sun Mar  5 04:09:18 2017
New Revision: 314693
URL: https://svnweb.freebsd.org/changeset/base/314693

Log:
    Change /etc/rmt symlink from absolute to relative path,
    correcting the mistake made in r6499
    Approved by:        grehan
    MFC after:  1 week

Modified:
    head/usr.sbin/rmt/Makefile

Modified: head/usr.sbin/rmt/Makefile
==============================================================================
--- head/usr.sbin/rmt/Makefile  Sun Mar  5 04:02:47 2017        (r314692)
+++ head/usr.sbin/rmt/Makefile  Sun Mar  5 04:09:18 2017        (r314693)
@@ -7,6 +7,6 @@ MAN=    rmt.8
   # called from /usr/src/etc/Makefile
   etc-rmt:
        rm -f ${DESTDIR}/etc/rmt
-       ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt
+       ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt
I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}/etc/rmt
find /usr/src | xargs grep INSTALL_RSYM
(no results)

Sorry, no prior work does this, perhaps once I get done sweeping the
absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to
sweep all ln -s out and propage this internal bsd.lib.mk function out
to the rest of the source tree?

find /usr/share/mk/ | xargs grep INSTALL_RSYM
/usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?=     ${INSTALL} ${RSYMLINK}
/usr/share/mk/bsd.lib.mk:       ${INSTALL_RSYMLINK} 
${TAG_ARGS:D${TAG_ARGS},development} ${SHLIB_NAME} 
${DESTDIR}${_LIBDIR}/${SHLIB_LINK}
/usr/share/mk/bsd.lib.mk:       ${INSTALL_RSYMLINK} ${TAG_ARGS} 
${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \
/usr/share/mk/bsd.lib.mk:       ${INSTALL_RSYMLINK} 
${TAG_ARGS:D${TAG_ARGS},development} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \
/usr/share/mk/bsd.lib.mk:       ${INSTALL_RSYMLINK} ${TAG_ARGS} 
${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \

This is called from within bsd.lib.mk only, do we want to use this for
all symbolics links in the source tree?  If so I would of though the
person adding this functionality to the .mk files would of made
a tree sweeping looking for that and making those changes as well.
I've been playing around with libpathconv which converts abs paths to
relative paths etc.
I'w working on the patch to ln to add the -a and -r options that some other
versions have.

you can specify an absolute path but ln -r (abspath) will generate a
relative link.
my target was the exact absolute symlinks that you are targeting.

Work commitments have made me lay down tools but this reminds me to pick it
up again.
(libpathconv is in the tree at /lib/libpathconv, but I got interrupted half
way through..
I'll do the other half..
But install -l rs does exactly that, why adding a new mechanism? and install
works with metalog as stated earlier so for the build system it might be better.

Which reminds me multiple people have asked you if it won't be a good idea to
merge your libpathconv into libutil rather that having a new library for just 2
functions. DSO has a price and you haven't replied, will you consider merging
it?

Best regards,
Bapt

I will put it in libutil, but don't want to thrash too much so I'll do that with the ln patch.

I hadn't thought that was a possibility originally.

I need the ln patch myself and there are other systems that have it so I'm happy to do the work.

if install can do that I'm happy to hear it. Nice to learn about it..

Does that mean that libpathconv is already somewhere in our system as install is of the programs that was changed in hte initial pathconv release many years ago.




_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to