-- Start of PGP signed section.
[ Charset UTF-8 unsupported, converting... ]
>
> > On Mar 7, 2017, at 01:04, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net>
> > wrote:
> >
> >>>
> >>> On Mar 6, 2017, at 21:50, Rodney W. Grimes
> >>> <free...@pdx.rh.cn85.dnsmgr.net> wrote:
> >>>
> >>>>> On Mar 6, 2017, at 21:10, Rodney W. Grimes <rgri...@freebsd.org> wrote:
> >>>>>
> >>>>> Author: rgrimes
> >>>>> Date: Tue Mar 7 05:10:38 2017
> >>>>> New Revision: 314833
> >>>>> URL: https://svnweb.freebsd.org/changeset/base/314833
> >>> ...
> >>>
> >>>>>
> >>>>> -SYMLINKS+= ${LIBDIR}/${SHLIB_NAME} /usr/lib/libxo/encoder/test.enc
> >>>>> +SYMLINKS+= ../../../tests/lib/libxo/${SHLIB_NAME}
> >>>>> /usr/lib/libxo/encoder/test.enc
> >>>>
> >>>> This change breaks setting TESTSBASE != /usr/tests . Please fix (my
> >>>> employer depends on this being functional).
> >>>> Thanks,
> >>>
> >>> I am just going to revert this until the issue with SYMLINKS vs RSYMLINKS
> >>> and
> >>> probably a much better fix in bsd.*.mk can be implemented. I can live
> >>> with
> >>> one last nasty wart of an absolute link in DESTDIR until then. The
> >>> important
> >>> functional ones are gone now.
> >>>
> >>> To fix this without changing SYMLINKS would involve adding a local
> >>> install:
> >>> target which would be more mess than having the one absolute link.
> >>
> >> The proposed enhancement for bsd.links.mk for RSYMLINKS can be found here:
> >> https://reviews.freebsd.org/D9919 .
> >
> > I dont think that is what bapt/bdrewery had in mind, I think they wanted to
> > replicate the SYMLINK= as RSYMLINK= and use that when needed.
> >
> > I have thought about this and we do not ever want absolute links in the
> > tree,
> > so much simpler fix is to just convert SYMLINKS to call INSTALL_RSYMLINKS
> > instead of INSTALL_SYMLINKS and bam, its all fixed and shall always be
> > fixed,
> > and as long as no one uses INSTALL_SYMLINKS.
>
> SYMLINKS has been around since r245752. I personally don?t know if it?s wise
> to remove functionality that?s been ?in production? for 4+ years.
SYMLINKS has been around since 198x.
> Making the target intelligently use one command over the other might seem ok,
> but it could have unintended consequences.
> I think it?s best to have another well-documented variable that uses
> INSTALL_RSYMLINK vs INSTALL_SYMLINK.
It has 0 consequencies, it actually achives that all installed symbolic
links be relative, which is how things should be. There is no doubt about
this, if you have doubt please defer to myself, Julian Elisher and some other
grey beards that know about this. You simply do NOT want absolute path symbolic
links in the distribution, ever!
> Also, in the CR, please note that the SYMLINKS piece doesn?t prefix source
> targets with ${DESTDIR},
whereas the LINKS (and soon to be RSYMLINKS portion) will need it in order to
compute the right paths and execute the right behavior. Otherwise, you?re going
to be breaking someone?s use for SYMLINKS for no good reason.
That is correct, LINKS need 2 absolute paths to things in DESTDIR to create the
proper hardlink,
where as SYMLINKS need the prooper DESTDIR relative source to place as the link
body at
the target.
I suggest your run a make installworld DESTDIR=/some/place and see just how
broken your
symbolic links end up if you add ${DESTDIOR] to both sides of SYMLINK
> -Ngie
--
Rod Grimes rgri...@freebsd.org
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
