On Mon, 3 Jun 2024 at 11:40, Fabio Berton via lists.openembedded.org
wrote:
> Based on this, I would say that we don't want to build tests unless ptests
> are enabled (so the argument that building tests also tests the code is
> moot). In turn, it may be sensible to use the default CMake option
On Mon, 3 Jun 2024 at 11:40, Fabio Berton via lists.openembedded.org
wrote:
> Based on this, I would say that we don't want to build tests unless ptests
> are enabled (so the argument that building tests also tests the code is
> moot). In turn, it may be sensible to use the default CMake option
Hi Alex,
I ran a few builds disabling CMake DBUILD_TESTING and the build time was about
the same. I'm not sure if by building plenty of recipes we can see a difference
in build time, since bitbake needs to build all the recipe dependencies that
use cmake bbclass.
Looking for some recipes that
You can build everything with 'bitbake world' (and it's going to be long).
Build times are recorded into tmp/buildstats, if that is enabled (see
default local.conf to see how if you're not already using that).
Alex
On Wed, 24 Apr 2024 at 09:56, Fabio Berton wrote:
>
> Hi Alex,
>
> What should I
Hi Alex,
What should I test to measure build time, all recipes that use cmake
from OE-Core and meta-openembedded? Is there a way to build all recipes,
or should I find all recipes that use cmake and run bitbake ?
Regards,
Fabio Berton
On 4/23/2024 2:01 PM, Alexander Kanavin wrote:
I'm not
I'm not sure I like the idea. This is going to break ptests or other
usage of CTest in cmake-based recipes that aren't under our control.
Building tests is also a test in itself even if you don't run them.
I'd say unless this adds significantly to build times we should leave
it as it is.
Alex
On
I've noticed that some recipes, like json-c [1], which use the cmake
bbclass, are generating files that aren't being used. This is because
CMake sets the BUILD_TESTING option to ON by default. According to the
CMake documentation [2], when CTest is included, as json-c does here
[3], the module