Re: [Discuss-gnuradio] building with cmake

[Marcus Müller]

Hi Robert,

as Nathan pointed out, there's no formal documentation that we'd be aware of. So let me just give you a recapitulation of the events, and the mood back in these days when GNU Radio made the switch.

Whilst I can fully understand that you'd like to see the compiler calls (which is possible with "make VERBOSE=1", like Nathan explained), autotools had to die (in agony).

At the university lab where I spent a lot of my days, the win in GNU Radio development productivity was massive:
Whereas adding a block to a project required changing multiple things in multiple places, often leading to non-reproducible failures in the autogen part of the pre-build process.
In fact, I think every Out-Of-Tree module suffered from one such "what does autotools do now?" moment back then.

Then, someone™(it was Moritz, IIRC) ported the out-of-tree module template to CMake, because he'd made good experiences with that. It worked, quite out of the box.
It made build errors so much clearer, and took the workload of getting that darn thing to build away to debugging your actual software (and not the software written in M4 that builds the scripts that configure your build), that the GR dev productivity, at least in the lab where I used to hang around, went significantly up (or at least, there were less groups of students and the occasional advisor, huddled together over screens, trying to understand why the hell things wouldn't even build).

Thus, the desire to adopt that build system to the whole GR tree was great, and such was the joy when that happened.
Negative effects were:

• additional build-time dependency (CMake), but other dependencies had adopted CMake, too, so this wasn't actually a big disadvantage in many cases
• having a period where both systems were in place was additional workload for the maintainers

Positive effects are:

• No bootstrapping
  
• Faster configuration
• Clearer "you're missing this, so I can't enable that" during cmake run compared to failing/incomplete ./configure
• modular builds became possible: Faster, less memory
• getting rid of every single line of M4
• better make install / uninstall
  
• build type handling improved vastly (-DCMAKE_BUILD_TYPE=...)
• cmake's architecture of letting users simply add FindXYZ.cmake scripts led to vastly improved portability of out-of-tree modules
• automatical re-configuration upon changes to the build system (ie. you change any CMakeLists.txt, run make, cmake runs again and makes sure things are somewhat coherent -- still a few caveats, mostly because of SWIG)
• Proper & Full support & enforcing of out-of-source builds
  

Cheers,
Marcus

On 13.09.2015 13:38, Robert Durkacz wrote:

I am interested in the gnuradio build system.

I last looked at gnuradio several years ago. Since then you have
adopted cmake in place of autotools.
cmake produces its own style of make files which even invoke cmake
again. When I built gnuradio I got one build error. It was difficult
to track down the cause because the output of the build process does
not print the command lines. Obviously it is helpful to know the
command line that failed.
My question is, is there some recommended way to get the command lines
printed out as they are executed.
Also there is something called pybombs. Is this an alternative to
cmake? If so is the gnuradio build system in a state of flux?
Can anyone point me to some document or forum where the whys and
wherefores of the build system are discussed?

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio