From: Jeremy Puhlman <jpuhlman@...> Signed-off-by: Jeremy A. Puhlman <jpuhlman@...> --- meta-cgl-common/conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

My build machine has lots of RAM and I do builds in a 32GB tmpfs with rm_work (and no, I don't build webkit, which would make this impractical). As you say, with sufficient RAM the build speed is

Hi Laurent and Quentin - Thank you both so much for your help! I did just end up patching the source code for my recipe - I had to both add the 3 and remove the -mt, and the OS does build now! If

Some of these started 2 years ago. Probably Krogoth timeframe thru rocko. (Did I get the names right!) Not downloading from the net. But we had an inhouse git mirror of yocto. We tried being a

anyway this sounds like a complete rebuild not taking advantage of shard-state cache -- Yann Dirson <yann@...> Blade / Shadow -- http://shadow.tech

4 hours seems extremely long to me for a 8 core system, but I have not tried this in a while. Were you removing all the sources and re-downloading them for every build? From: <yocto@...> on behalf

My own experience (pardon me if already discussed) Fought the build times for several months - ending up eventually at 8 cores (but specifying 16 threads in poky builds). Best times for my build about

Well, I can't build with under 2 gigs per core or I run out of physical memory and kernel oom-killer kicks in to kill the build. Also can't run with yocto default parallel settings which only take

Other replies look good to me, here are few additions: If you want to compare how terrible your current VM compares with some other builders, you can

Hi Emily, You can create a patch for it. You can use devtool modify <your-recipe> and create the patch from there, you have access to the sources with that. devtool build <your-recipe> to check it

Hi Laurent - Unfortunately I don't have full control over the repo that's using boost_python-mt so I'm not sure I can switch it right now. I realize this is not a long-term solution, as I'll need to

Seems a bit excessive to buy hardware just to handle a particular corner case. Most of OE/Yocto code is plain C, not even C++. My rig only has 8GB but doesn't run into memory issues during big GUI

Depends on what you are building. Building non-trivial C++ code (e.g. webkitgtk) with 24 cores but only 32 GB RAM will not work, for such code you need more than 2 GB/core. I would buy 128 GB RAM to

Sorry - wrong number. My rig does not have a 1900, but an "AMD Ryzen 7 1700".

I have to say that AMD aggressively pursuing core count increase on consumer level CPUs is awesome news for the YP. Previously, you had to buy some hugely overpriced Xeons or similar to be able to

Hi, In my company we have tested some "big Ryzen" configurations to speed up Yocto builds. The conclusion of these tests is that the build time is almost only related to the CPU score:

Big ryzen is a good choice. My home rig is a Ryzen 1900, with only 8GB RAM. It's way faster at OE yocto builds than the i7 at work that has 32GB RAM installed. My 8GB rig does not use swap space

What Mikko said is excellent advice. I'd recommend NVMe drives if you can. My build machine has two large M.2 NVMe drives, one is used for the working directory and the other for sstate, downloads

Drop all virtualization and go for Linux on bare metal. Then make sure there is enough(tm) physical RAM for each CPU thread. For a "big Ryzen" the 64G of RAM sounds too little. I'd go higher there,

Hey, We're currently using a VM on Windows and it's a lot slower than the native linux build (which is expected). We're looking into getting a dedicated build server for our team (basically a