Hi, Op 12-04-2021 om 04:25 schreef ChenQi: Yeah, so we would be having memwatch as a baby sitter. I would be nicer to have it built into bitbake, but this would work too.

Signed-off-by: Anton Antonov <Anton.Antonov@...> --- .../recipes-parsec/parsec-service/parsec-service_0.7.0.bb | 4 ++-- meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb | 3 +--

I'd suggest you place that tarball into some artefact storage, and have it listed in SRC_URI. Then the standard Yocto mechanism for fetching, checksumming, caching and unpacking tarballs kicks in, so

Hi Alex, OK, understood. If the "local download cache path" is well-known (this is not by any chance $DL_DIR?), then we could create a tar from the vendor directory (which is created when you call

Reproducibility means anyone can run a build at any point in the future even if the upstream repositories are gone, so all inputs must be stored in a local download cache, which is the other thing

Hi Robert, thanks for your thoughts. I see your point and the last thing I want is "NOT reproducable builds". But dependency management in go is not that arbitrary as it may seem. Dependencies and

Alexander (whom you cc'ed here as well) wrote a long time ago on the mailing list[1] about this stuff. We have a couple of issues with those "modern" languages like go, which behave quite differently

Hello Konrad, thanks for your reply. It is interesting that you mention vendoring, because we tried this approach as well. We started to develop a "go-mod-vendor.bbclass", which retrieves

Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E:

Hi, My comments are in-line. The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;) Is Linux your build host? Then you can use cgroups to limit resources

I think you write a script to do all the WATCH-STOP-CONTINUE stuff. e.g. memwatch bitbake core-image-minimal Options could be added. e.g. memwatch --interval 5

make already has -l option for limiting new instances if load average is too high, so it's only natural to add a RAM limiter too. -l [N], --load-average[=N], --max-load[=N]

Op 11-04-2021 om 17:55 schreef Alexander Kanavin: Bitbake does a lot of babysitting anyway :-) And is pretty good at it too. To me, fixing make et al. is more work and less effective then adding a

And neither they should. They can simply abstain from spawning new compilers if used RAM is, say, at 90% total. Then bitbake does not have to get involved in babysitting those makes. Alex

Op 11-04-2021 om 17:27 schreef Alexander Kanavin: Yes, and make project doesn't care, because make is called with -j 16 so that is what it does. So here's my pitch: bitbake can stop processes spawned

This has been discussed several times in the past - the conclusion usually is that first this needs to be addresses upstream in make and ninja, e.g. that they support throttling new compiler instances

My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space). 16GB of RAM has always been more then enough with 4 core + HT, but now

Well AFAIK your observation is correct, go-mod.bbclass doesn't work a in BB_NO_NETWORK-safe manner. What you could do is to provide all the dependencies manually and add them via DEPENDS, which is

Hi, we are developing an application in go and use the "go-mod" bb-class from poky. This works fine. However, the problem is, that the dependencies in go.mod are now fetched in the compile phase

Hi, Just want to ask if anyone working/can share a recipe for a pycoral package (https://github.com/google-coral/pycoral). I have some barebone but seems not straightforward. It's using bazel build