[cfe-dev] Building Clang on Windows

[Fábio Picchi via cfe-dev]

> The problem is that by default VS2017 builds Clang in parallel to how
many cores you have

That would explain my problem in building clang then as I have an eight
core Ryzen 7 1700X with only 8GB of RAM. I will try to build with parallel
building off...

But did ninja ignore these build options? Because I was able to build clang
using it without any problem.

I will look into it and post some results tomorrow.

On Sun, Oct 7, 2018 at 7:11 PM Bruce Hoult via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 16GB is about the minimal amount of RAM you want for a quad core developer
> system these days -- I build mine with 32G in order to have room for a
> decent amount of disk caching. 16GB a completely crazy amount of RAM for 32
> cores. I wouldn't go with less than 128GB. This time last year I built a
> system with an i9 with 18 cores and 64GB and it was just barely enough --
> 32GB would have been tragic.
>
> I note that AWS "general purpose" instances (e.g. M4/M5) have 4 GB per
> vCPU (hyperthread). "Compute Optimised" have 2 GB per vCPU. I find the M5
> instances much better balanced for software development than the C5
> instances, at about a 12% price premium.
>
> On Sun, Oct 7, 2018 at 7:32 AM, Hussien Hussien via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> The problem is that by default VS2017 builds Clang in parallel to how
>> many cores you have. When I build LLVM/Clang, I've noticed the default
>> setting will almost instantly consume 100% of my RAM and I have 16GB of RAM
>> and 32cores.
>>
>> To turn off parallel building, mark the appropriate CMAKE variables:
>>
>> LLVM_PARALLEL_COMPILE_JOBS:STRING
>> Define the maximum number of concurrent compilation jobs.
>> LLVM_PARALLEL_LINK_JOBS:STRING
>> Define the maximum number of concurrent link jobs.
>>
>> Also in Visual Studio, in Tools > Projects and Solutions > Build and Run,
>> set
>> 'maximum number of parallel project builds to 1.
>>
>> Hussien H.
>>
>> On Sun, Oct 7, 2018 at 9:22 AM degski via cfe-dev <cfe-dev at lists.llvm.org>
>> wrote:
>>
>>> Sorry to barge in.
>>>
>>> >> I remember doing so at one point when I was still using Windows, and
>>> found
>>> >> my system much more responsive overall. But that was ~10 years ago
>>> and I
>>> >> guess it's not a common setup.
>>>
>>> 10 years ago does not seem very relevant, both Windows and VS are very
>>> different now. Also "... found my system much more responsive overall ..."
>>> very much sounds like placebo/snake-oil.
>>>
>>> >> If msbuild is 32-bit, why would that cause the (64-bit?) cl.exe
>>> process to
>>> >> run out of memory?
>>>
>>> I doubt msbuild is allocating much memory at all, but is the 64-bit
>>> version of cl.exe being called from msbuild? You need to up the build
>>> output so you can see what compiler is being called. Sounds like ninja is
>>> calling the 64-bit version, while msbuild is (could be, I'm speculating)
>>> using the 32-bit version to cross-build [and runs out of addressable
>>> space]. The VS defaults are all 32-bit.
>>>
>>> degski
>>> --
>>> *“If something cannot go on forever, it will stop" - Herbert Stein*
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181007/b4a638ac/attachment.html>