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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
