Multi-jobs build

[eplanet]

Hello! I made this minor modification locally, in order to parallelize the build using the number of cores available on the machine it is run on.

[gdt]

I don't think this is ok, as it appears to unconditionally use non-portable constructs, basically assuming that all the world is Linux.

Separately, whether someone wants to build in parallel and with how many jobs is a decision for the user. Sometimes people don't want to stress the machine and would prefer to just let it run a bit longer, and sometimes people want even more jobs than cores, since the point is having something to do during IO.

I find that building rtl_433 is quite fast, compared to modern bloatware (like cmake). You didn't post any times, which could be useful in assessing what the real issues are. I did a test, on NetBSD 10 amd64, with an 8-core CPU (9th gen i7), and:

• no -j: 22.5s
• j4: 6.5s
• -j8: 4.4s
• -j12: 4.4s
  However, I very rarely do that, because the dependency tracking works, and ~always building without cleaning works.

I would suggest instead having the script accept -jN and pass it on. This avoids both the the portability issue and the overriding-preference issue, and lets you call it how you like.

[eplanet]

This is very true indeed, I really like your argument passing proposal so I changed the behavior to actually parse input of the script and pass the number of jobs from -j N to make.

Side note, in the initial solution if nproc wouldn't exist the job wouldn't actually fail, it would default to make without arguments.

[gdt]

Side note, in the initial solution if nproc wouldn't exist the job wouldn't actually fail, it would default to make without arguments.

Maybe, but I don't think it's ok to have things fail because you're not on the author's OS. But thanks for adjusting and I'll have a look.

[gdt]

Looks ok to me. I pushed the 'allow workflow' button.

[zuckschwerdt]

There is a catch: The do_build.sh is part of the CI and not intended for users. We should at some point get rid of that script or maybe hide it.

A recommended way to build is e.g.
cmake -GNinja .. && cmake --build . -j 10

[zuckschwerdt]

I've shuffled the scripts away to .ci/scripts.

We should check that we have clear build instructions in all places (recommending Ninja maybe) and no mentions of the do_build.sh.

[eplanet]

I suppose it means this PR doesn't make sense anymore? Felt like do_build.sh could be used by users more simply than copy/pasting the build instructions.

[gdt]

Maybe but the other side of the coin is that the normal approach with cmake is

mkdir build
cd build
cmake ..
gmake

and if that doesn't work better to address that. It is good that CI and user things are being cleaned up though.
and

[zuckschwerdt]

The major benefit of not using wrapper scripts is good tool integration. IDEs should be able to discover and build this project with (visual) configuration hints and test integration.

[eplanet]

Closing this PR according to the discussion's conclusion.