discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr-trellis broken on next branch


From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] gr-trellis broken on next branch
Date: Fri, 21 Oct 2011 15:58:49 -0400
User-agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Sean,

this is strange...
I built it with cmake and passes all checks...

Achilleas

On 10/21/2011 3:23 PM, Nowlan, Sean wrote:
The gnuradio "next" branch builds fine for me but "make check" fails for
gr-trellis.

Sean
------------------------------------------------------------------------
*From:* address@hidden
address@hidden on behalf
of Tom Rondeau address@hidden
*Sent:* Friday, October 21, 2011 3:19 PM
*To:* address@hidden
*Cc:* address@hidden
*Subject:* Re: [Discuss-gnuradio] gr-trellis broken on next branch

On Thu, Oct 20, 2011 at 10:34 PM, Achilleas Anastasopoulos
<address@hidden <mailto:address@hidden>> wrote:

    After installing the next branch i realized that gr-trellis is not
    working properly!

    This is due to some work (by Ben Raynwar) that makes gr-trellis
    dependent on gr-digital (???)
    In particular the constants related to trellis_metric_type.h cannot be
    accessed in python/grc
    as part of the trellis module, but as part of the digital module
    (this problem appears for instance if you run some of the pccc/sccc
    examples in gnuradio-examples/grc/trellis).

    This can be an easy fix (import digital in all the grc blocks
    requiring metric types, and make appropriate changes).

    However I wonder what is the point of making a self-contained
    module like gr-trellis dependent on another module (gr-digital)
    If the only reason is to to use the "constellation" object in the
    "metrics" blocks then these blocks should
    reside in the gr-digital module instead of the gr-trellis, so that the
    latter can still be self-contained.

    Ben, can you please explain what is your rational in doing these
    changes.

    thanks,
    Achilleas



Achilleas,
This was my doing. Ben had moved the metric types into gnuradio-core to
work with his constellation work, so I moved them over with everything
else into gr-digital. I then made gr-trellis depend on gr-digital
because of this. Because gr-trellis is an implementation of digital
modulation, it makes sense that it should depend on gr-digital.

I made sure that gr-trellis would both build and pass 'make check,' so
the QA code is obviously not testing all of the proper dependencies and
cases in gr-trellis. We need to fix that to make sure the applications
still run as we move stuff around.

Depending on what gr-trellis requires out of gr-digital, we could
possibly import digital into the trellis module inside of the
__init__.py file.

Tom




reply via email to

[Prev in Thread] Current Thread [Next in Thread]