svn commit: r308181 - in head: . share/mk

[Brooks Davis]

On Wed, Nov 02, 2016 at 04:55:22AM -0230, Jonathan Anderson wrote:
> 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 affected anything compiled with bmake, and indeed, I'd imagine that adding a .c->.ll rule alongside .c->.o could cause problems with C++ lex rules. In fact, part of brooks' original motivation for introducing .llo suffixes was to avoid name conflicts (although conflicts with program IR like we're introducing in this commit). The changes in this commit should only be picked up by things that explicit include bsd.{lib,prog}.mk, however, and they also have slightly more esoteric names (e.g., progname.full.ll) that 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. I don't suppose you have a list of the ports that failed after your r307823 change so that I could do spot checks?

As a bit of background, the original motivation for the .bco and .llo
files what that I wanted to differentiate between IR files produced from
single translation units (.c files) and IR files produced by llvm-link
so I didn't have to worry about things like name space collisions in the
case of transitions like:

                  clang                   llvm-link  opt      ld
(prog.c, utils.c) => (prog.llo, util.llo) => prog.ll => prog.o => prog

Part of the fun is that you might instead want:

                  clang                   opt                 ld
(prog.c, utils.c) => (prog.llo, util.llo) => (prog.o, util.o) => prog

and for extra fun you might insert instrumentation at any IR stage so
yet more suffixes may be required if your tools don't fit neatly into
clang, opt, etc plugins.

Make is lousy at this stuff so a certain about of ugliness is likely
to remain required.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20161102/9b3798b7/attachment.sig>