discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Gras make error


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Gras make error
Date: Fri, 14 Jun 2013 05:23:06 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

> 
> I am especially interested in gr-extras, what seems to be a part of gras
> now. Will this be available for gnuradio 3.7 standalone, or just as part of
> gras? I do not like the idea of gras hovering over gnuradio, but like much
> more an independent gnuradio installation in its standard folder, and the
> additional stuff a bit more separated from this :)

Well actually its a really granular architecture where every little
piece is simple, has its own purposes, and has its own value
individually. To give you an idea of the components, here is the little
dependency map from the build guide: http://i.imgur.com/U4QvBgd.png

I happen to be bringing in each component as a submodule into GRAS so
its easy to version and easy to install as one project. But the reality
is that the projects could be installed individually, or even used for
unrelated purposes.

I hope that some of this submodule business changes in the long run
because I ultimately dont want to track gnuradio changes in a submodule.
I would rather that mainline gnuradio master have an option to use the
advanced scheduler. Thats why for my 3.7 support work, I am producing a
mergable branch so the underlying scheduler is just another compile time
selection. Thats basically working, but the remaining challenge is to
get all the different APIs and features working together, so you can
have a "superset" of APIs, features, and blocks.

And so back to GrExtras: this is actually a standalone/out-of-tree
project, which contains just blocks. GrExtras was intended to make use
of, and to demonstrate the new scheduler features and API found in GRAS,
so naturally it depends on GRAS. But it doesnt make sense to depend on
gnuradio 3.7 or rewrite for 3.7 since in this case, the motivation for
extras was to demonstrate these cool new capabilities.

I hope that clarifies things. Everything feels like quite a jumble of
APIs and git repos. Hopefully things get nailed down, stabilized, and
versioned later this summer.

-josh

PS

As I write this email, I am using dot to visualize a deadlock condition
in one of the QA tests on my 3.7 support branch. Thought I would share
the png: http://i.imgur.com/QfLz4aL.png

:-)



reply via email to

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