On Mon, Sep 26, 2011 at 11:48 AM, Ben Hilburn <[email protected]> wrote:
> Restarting the discussion for a small point: > > > 1) It separates publicly installed headers vs private headers in the lib > > directory. > > I think this, honestly, is the best argument for having the separate > directory. In terms of project navigation, I think this is really helpful, > and makes sense. > > > > 2) Its a cleaner separation of API and implementation. > > > 3) Its easier to point doxygen to the public headers and keep it from > > parsing everything in "lib". > > This is the point I wanted to comment on. I've worked on a number of > projects that point Doxygen only to include/, and projects that point to > both include/ and lib/. Honestly, and while this is obviously highly > subjective and easily swapped back and forth for anyone that cares, I > actually prefer including the lib/ directory as well. There is usually a > whole lot of stuff in the the implementation files that aren't declared in > the headers, and a lot of it is usually extremely helpful (at least to me) > when I'm hacking around. > > Again, this is obviously preference. If you only want Doxygen to document > the public GNURadio API, then obviously you only want to point it to > include. For actually developing _inside_ of GNURadio, however, I often > find having the lib/ documentation to be very helpful. > > Cheers, > Ben > I agree with everything you've said here. I think we'll be including both. There's some maintenance work on Doxygen that I need to sort out soon, so making sure we're picking up everything that we want is going to be part of it. Thanks, Tom > On Mon, Sep 26, 2011 at 5:10 AM, Tom Rondeau <[email protected]>wrote: > >> On Mon, Sep 26, 2011 at 3:39 AM, Martin Braun <[email protected]>wrote: >> >>> On Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom Rondeau wrote: >>> > On Sat, Sep 17, 2011 at 3:14 PM, Martin Braun <[email protected]> >>> wrote: >>> > >>> > I'd like to point out a disadvantage to get a discussion going: >>> > While you're developing, this might be an inconvenience because the >>> > files are physically separated. Most IDEs/editors have many >>> features >>> > such as tagging, switching from headers to sources and vice versa, >>> 'go >>> > to file at cursor' commands etc. If half of the files are somewhere >>> > else, one has to set up the editor specifically for this dir >>> structure >>> > to do all of this. >>> > >>> > >>> > It's a logical separation that a lot of projects use. I know that I'm a >>> bit >>> > biased because my "IDE" is Emacs, but I don't recall having project >>> files in >>> > different directories was a problem. Way back when I developed in >>> Windows and >>> > used Visual Studio, this wasn't an issue, but that could have been due >>> to the >>> > project file that VS kept. >>> > >>> > >>> > We haven't made it part of our official standard, but talking with both >>> > Johnathan and Josh last week about it, I was thinking that we would. >>> I'm not >>> > sure that your argument here has quite convinced me that it'll be a >>> problem. >>> >>> To be honest, >>> >>> after re-reading this, I'm not even convinced myself. >>> Sometimes I just like to argue :) >>> >>> Martin >> >> >> Always good to have the discussion. I think we're settled on the use of >> include directory, then. >> >> Thanks! >> Tom >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
