Greg Troxel wrote: > I think the big question is what kind of top-level structure to be > imposed on blocks intended for specific purposes.
This is indeed an open issue I've been "silently dropping." No thought went into organizing the new repository other than to combine what already existed into one place. We simply put all the independently developed components at the root of the hierarchy, then refactored the build system into a single master configure/recursive make. "Dependencies" are handled by fixing the order of compilation. This ensures that generated files in one component (like the core) are available in the build tree when they are needed by later components. This flat system works for now, but definitely does not scale. For "Release 3.0" we're going to So for the 802.11 stuff, I'd take the pragmatic step of first putting it as its own top-level component, and we'd put it in the compile order after mblock. I can help you do that. Then, you can "at your leisure" begin refactoring bits and pieces of it into prior components. Some stuff you mention should go into the core. Maybe there are routines elsewhere that people have written you can reuse, and eliminate some of the code you've done that replicates them. Maybe some of your blocks are useful enough to be reused in other projects and a separate component tree (like gr-packet as you mention) should be created to house them. But these are all things you can do over time, while transparently preserving the outward functionality of the 802.11 code in its own component module already integrated into the build system. Back to the bigger picture, though. I do think the combination of all the existing components, as well as whats planned in the near future (mblocks, 802.11, direction finding algorithms, radiopaging decoders, new hardware, to name a few) calls for a re-think of how all of the G NU Radio tree is organized and built. We do (or will) have things like: System and runtime: core, pmt, mblock Core DSP stuff: fast math routines, filters, "piping", etc. SDR/hardware drivers: usrp, ezdop, sdr1000 Audio drivers: alsa, oss, osx, windows, jack, portaudio Additional DSP stuff: AM, FM, SSB, PSK, FSK, trellis, ecc, packetizing, vocoding, etc Networking: 802.11x Specialty application areas: radio astronomy, direction finding, radar, pagers This does suggest a more hierarchical organization around these lines. -Johnathan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
