On 10/19/2010 05:45 PM, Josh Blum wrote: > >> There's an argument to be made for this. It'll go into the thinking >> about the refactoring of the code. >> > > blks2impl must be burned > > I think the structure in the gr-noaa directory is a good example of > how to organize a set of related blocks and applications. > >> There is also the concept of using SWIG's XML output for the GRC >> files. I've only played around a bit with them, but it's something to >> look into if you haven't already. It looks like it captures _most_ of >> the information about the blocks that is exposed in the GRC xml files. >> It's fairly expressive output, so we'd have to see if it actually >> covers everything necessary for GRC to use with updated parsing. >> >> Have you already looked at, and dismissed, this, Josh? >> > > I have not looked at nor have I dismissed the possibility. There are > certain visually appealing things you can do like hiding parameters > that dont matter when another parameter is set, or grouping two > similar blocks that have different outputs. I believe that there is no > general abstraction on how to do this and that generated xml files > will be somewhat lacking. That said, maybe generating the xml files > might be useful for enough of the blocks that its worth figuring out. > Maybe we can have a middle ground and find a way to generate the xml > and leave a place to get extra block specific information into the > generator. > > Basically, I will take a look at the SWIG XML when I get the chance. > > -Josh > > I think having the XML generated automatically (mostly) from the underlying SWIG/C++ is a very nifty idea. But I think I agree with Josh that some of the semantics are going to need to be "grafted in" post-facto. Unless we can come up with some clever way of deriving those semantics from the underlying C++ code.
But moving towards a single, "de facto" location for all of this, and having the rest be derived by an automated build-time process would be sweet. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
