Date: Wed, 02 Nov 2016 04:55:22 -0230 From: "Jonathan Anderson" <jonathan@FreeBSD.org> To: "Dimitry Andric" <dim@FreeBSD.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, "Ed Maste" <emaste@freebsd.org> Subject: Re: svn commit: r308181 - in head: . share/mk Message-ID: <69A64340-FE51-4AF0-9905-B46220D041E9@FreeBSD.org> In-Reply-To: <46715A69-03C5-404F-B133-C8FE89D59A9B@FreeBSD.org> References: <201611012127.uA1LRg0B045900@repo.freebsd.org> <46715A69-03C5-404F-B133-C8FE89D59A9B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 3156 and 4880).
--=_MailMate_C088D1FA-BC25-4B93-9B58-A7469C1D18E8_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Hi,
On 1 Nov 2016, at 21:10, Dimitry Andric wrote:
> Please note, I reverted r307823 (which changed the suffixes from .bco
> and .llo to .bc and .ll) in r308003, since it caused a number of ports
> failures. These ports were already using .ll as a suffix for C++ lex
> scripts.
The changes to bsd.suffixes-posix.mk (included by sys.mk) would have affe=
cted anything compiled with bmake, and indeed, I'd imagine that adding a =
=2Ec->.ll rule alongside .c->.o could cause problems with C++ lex rules. =
In fact, part of brooks' original motivation for introducing .llo suffixe=
s was to avoid name conflicts (although conflicts with program IR like we=
're introducing in this commit). The changes in this commit should only b=
e picked up by things that explicit include bsd.{lib,prog}.mk, however, a=
nd they also have slightly more esoteric names (e.g., progname.full.ll) t=
hat are less likely to cause a conflict. Perhaps I ought to have done an =
exp-run, but I suspect that this commit will cause much less / no fallout=
=2E I don't suppose you have a list of the ports that failed after your r=
307823 change so that I could do spot checks?
>> # prefer .s to a .c, add .po, remove stuff not used in the BSD librari=
es
>> # .pico used for PIC object files
>> -.SUFFIXES: .out .o .po .pico .S .asm .s .c .cc .cpp .cxx .C .f .y .l =
=2Eln
>> +.SUFFIXES: .out .o .bc .ll .po .pico .S .asm .s .c .cc .cpp .cxx .C .=
f .y .l .ln
>
> So here, please use .bco and .llo.
The "o" in the suffix indicates that the file is analogous to an object f=
ile, which is not really the case with the rules added here in r308181. I=
'd be happy to consider a different suffix if we get ports fallout, but I=
'd like to wait for evidence of such fallout before renaming these suffix=
es away from upstream's usage. I think that we should stick with the upst=
ream suffixes unless there's a good reason not to (such as collisions wit=
h lex things as affected r307823).
>> @@ -199,6 +199,18 @@ lib${LIB_PRIVATE}${LIB}_p.a: ${POBJS}
>> ${RANLIB} ${RANLIBFLAGS} ${.TARGET}
>> .endif
>>
>> +.if defined(LLVM_LINK)
>> +BCOBJS=3D ${OBJS:.o=3D.bco} ${STATICOBJS:.o=3D.bco}
>> +LLOBJS=3D ${OBJS:.o=3D.llo} ${STATICOBJS:.o=3D.llo}
>
> But apparently you already used those suffixes here.
Yup, because of the "object file" analogy.
>> -.SUFFIXES: .out .o .c .cc .cpp .cxx .C .m .y .l .ln .s .S .asm
>> +.SUFFIXES: .out .o .bc .c .cc .cpp .cxx .C .m .y .l .ll .ln .s .S .as=
m
>
> But not here, these should also be changed. Sorry for any confusion.
The .bco and .llo suffixes should already be included because of bsd.suff=
ixes-posix.mk (included from sys.mk). This SUFFIXES change, on the other =
hand, is to add the .ll and .bc suffixes for the final build products (IR=
"binaries" and "libraries").
I hope this clears up any confusion,
Jon
--
Jonathan Anderson
jonathan@FreeBSD.org
--=_MailMate_C088D1FA-BC25-4B93-9B58-A7469C1D18E8_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJYGZToAAoJEDusuBaTfFXcdPoQAJEB0SMMoIrbRvwYxrXg8yUn
HO2NfSDOR7mJVz4uPlpUScwfDbBgpqDo1MFxoewY8gP/lBpWBAfjVq5ngcLm2Z/j
4NednX3D2hXzk/E5VIxEFNK4uRC73ZCvzxs3tFLRCPNa1n9frQHtmCy4Af7tqQFU
D39jFZ3AHeqRkFI3u4mOAXRStWgQTr8NtbhoW3DsDkrKQvI4AL7vgNIKAXoyH2sG
RFvY9zL0ympT+O/vYjgB0RIBLWDP4WsmEPuAVrs8GnjEFQYJVpusDjfrjQefXtuf
m82O5n/2Q17cW6HnTuQdgOr6ZO5tp409+kgLsx/+P+0R1KcdgXgLp7zKnFKCZsXu
9Z9ROtrrCyTyQH9VWEPLDCpauvUitfWIaGRG03xepDzgXMrgfz/XsH22gZaH7oFH
Ah0CeYyaN/cWlXznnB8CbsSEpNJmOSnoZwnjLApeIPZZ8h/5wJnnjRF6A2JO9/Xw
7+ddeMruDnku+SOdPs6W4I0RYwwEomr63oS5wAE14VR+WLGffoDjm3U22Pit8r2W
t1WiK2aqCCLYVLpmb/hv1DEN7aPVR1SAePJM6pANAeR/mASdNqpWBHtSwlK9PHOt
7GWfghSBpO/OzQPxMGxKxNQApOw2sc6pJA+a+2rvx17MdArfdtBkbiwKaBTs1V+W
3VianVDHgT+uBB3Bbz6G
=GQM9
-----END PGP SIGNATURE-----
--=_MailMate_C088D1FA-BC25-4B93-9B58-A7469C1D18E8_=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69A64340-FE51-4AF0-9905-B46220D041E9>