On 04/06/17 10:26, Brooks Davis wrote: > On Wed, Apr 05, 2017 at 06:18:37PM -0700, Russell L. Carter wrote: >> On 04/05/17 15:32, Chris H wrote: >>> On Wed, 5 Apr 2017 21:51:40 +0000 Brooks Davis <brooks_at_freebsd.org> wrote >>> >>>> On Wed, Apr 05, 2017 at 11:42:16AM -0700, Chris H wrote: >>>>> OK I'm chasing -CURRENT, and I performed an initial >>>>> install, followed by a new world/kernel && ports about a >>>>> mos ago. Last Friday, I svn upped the system (src && ports), >>>>> rebuilt/installed world/kernel. I just began rebuilding >>>>> the ports, only to find that when finished, I will likely >>>>> end up with every version of llvm && clang from version 3 >>>>> to the now current 4. My build session is currently tying >>>>> nearly every core on the CPU with llvm builds. Given that >>>>> llvm4 comes in base. Is there *any* reason I can not insist >>>>> that the ports I upgrade, or build, just use the version(s) >>>>> of clang/llvm in base? If so. How do I inform the ports >>>>> that they may *only* use the version(s) in base? >>>> >>>> In general you can't. There are many reasons including: the base llvm >>>> doesn't include the requisite cmake bits for cmake based ports, some >>>> ports use unstable APIs and require specific LLVM versions, and some use >>>> LLVM tools or libraries that aren't built/installed as part of the base >>>> system. >>>> >>>> There are probably some ports where the base clang is fine but that's >>>> probably mostly down to someone getting USES variables right. >>>> >>>> -- Brooks >>> Grumble.. That's what I was afraid I might hear. >>> >>> Thanks, Brooks! Even if it's not what I was hoping to hear. :) >> >> FWIW, this is biting me hard right now too. I feel your >> pain... I'm a c++17 junky but I might have to let go of >> llvm-devel. > > If you want to track clang development, I would generally dis-recommend > the llvm-devel port. If you check out from upstream svn/git and build > with cmake and ninja, then you get pretty efficient incremental builds. > One nice think about the llvm build infrastructure is that you can use > it in place in the build's bin directory so you don't even need to > maintain an installed copy. That's a great idea. Obvious, too, in hindsight. I used to do this routinely for a number of the "big" packages but poudriere got so good apparently I got lazy. Thanks! Russell > -- Brooks >Received on Thu Apr 06 2017 - 15:43:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC