You can take a look at my last gr-dtv commit. It's very similar to what
you need to do.
https://github.com/gnuradio/gnuradio/commit/b90c574e2fbf0443e1eea2ee06779c2a85f86def
Files to consider:
gr-dtv/grc/CMakeLists.txt
gr-dtv/grc/dtv_block_tree.xml
gr-dtv/lib/CMakeLists.txt
gr-dtv/swig/dtv_swig.i
gr-dtv/include/gnuradio/dtv/CMakelists.txt
Actually, I forgot to update that last file. Pull request imminent.
Ron
On 09/23/2015 01:55 PM, Richard Bell wrote:
Sorry if these are obvious questions, but this is very not obvious to
me. As I understand it right now, it's not even a question of copy and
pasting files over to gr-analog, because that would overwrite the code
for all the other blocks, at least when it comes to swig. So let me
outline what I need to do and see how close I am to understanding this:
1) I can copy and paste the source code, the qa code and example files
over to corresponding gr-analog directories
2) I have to make changes to existing swig files in gr-analog, which
amounts to copying the various lines from my OOT swig into the
gr-analog swig
3) I don't know if I should be copying CMakeFile stuff or touching any
of that by hand. I need guidance here.
Am I supposed to build this and confirm its merged correctly before I
submit a pull request?
Rich
On Wed, Sep 23, 2015 at 12:06 PM, Tom Rondeau <t...@trondeau.com
<mailto:t...@trondeau.com>> wrote:
On Wed, Sep 23, 2015 at 2:38 PM, Richard Bell
<richard.be...@gmail.com <mailto:richard.be...@gmail.com>> wrote:
When merging my OOT module with the forked GNU Radio base,
should I hand copy the *.xml, *.h, *_impl.h, *_impl.cc,
qa_*.cc and qa_*.h in the appropriate gr-analog folder
locations, or should I just dump my entire OOT module into the
top level of the GNU Radio repo? I'm not familiar enough with
CMake and how it does its thing to think this through on my own.
Rich
You need to copy your code into gr-analog and make sure that the
cmake files and swig files are also updated accordingly.
Tom
On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech
<mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
On 09/23/2015 02:07 PM, Dan CaJacob wrote:
I like keeping the algorithm logic in comments. I can't
count how many times I have optimized something,
overwriting the original readable code, then come back in
a few months to discover I have no idea how it works anymore.
Months? Weeks for me :)
On Wed, Sep 23, 2015 at 1:54 PM Martin Braun
<martin.br...@ettus.com <mailto:martin.br...@ettus.com>>
wrote:
On 23.09.2015 10:39, Richard Bell wrote:
> Hey everyone,
>
> I'm in the process of submitting my first OOT
module for merge with GNU
> Radio base. It's a log gain AGC which converges
much faster then the
> current AGCs when the input signal energy is low.
I've read through the
> following link:
>
https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>
> 1) My first question relates to documentation. Up
to now, I've added
> documentation into my XML files as <doc></doc>
tags. To use Doxygen, am
> I correct to put them in the public *.h file? Is
this the only place it
> should go, or should I add it to the XML as well?
I've never been able
> to get my documentation to propagate through to the
GRC block without
> putting it into the XML, is this a sign of a problem?
You should only need to put your docs in the Doxygen
block.
> 2) If I understand the above link correctly, I
should fork GNU Radio,
> create a new branch which I might call Log_AGC, add
my code to that
> branch and then make a pull request. Am I
misunderstanding anything?
That's the way to go. See also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development
> 3) As far as code style goes, should I avoid using
>
> #define DEBUG
> #ifdef DEBUG
> std::cout << "Debug stuff" << "\n";
> #endif
Absolutely. Please use the logging interface. See also
http://gnuradio.org/doc/doxygen/page_logger.html
>
> statements to hide debug code? That is what I
currently do but I know
> it's not prevalent in the source.
>
> 4) I currently have an Optimize option in the GRC
block which picks
> between the way you would write the block if you
just used standard C++
> statements (not optimized) and if you use Volk
(optimized). Using
> control ports to compare the two, there is an
improvement with volk. But
> I like that someone looking into the block can see
how not to do it and
> then how to do it. Good for beginners jumping into
GNU Radio.
That's noble, but for core GNU Radio stuff it's
probably best if you
stick with the VOLK implementation.
M
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Very Respectfully,
Dan CaJacob
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto: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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
