#79 Separate the buffer command from the package

Major Effort
closed-later
3
2010-01-30
2008-03-02
Mark Hobley
No

The buffer command may be useful outside the scope of BRL-CAD. I propose the the buffer command is moved to a separate package.

Discussion

  • Sean Morrison

    Sean Morrison - 2008-03-02
    • assigned_to: nobody --> brlcad
    • status: open --> pending-later
     
  • Sean Morrison

    Sean Morrison - 2008-03-02

    Logged In: YES
    user_id=785737
    Originator: NO

    I'm not sure what that would actually give us that would be of use... That is predominantly what BRL-CAD _is_ ... it's a suite of over 400 tools like 'buffer' and _most_ of them are useful outside the scope of BRL-CAD. It's there comprehensive collective power that make them useful towards providing a powerful solid modeling system.

    Other than complicating the build system, though, I don't see what it buys _us_ to break the tools out into their own mini-projects. Please share what your thoughts are on how a break-out might work. It's been thought about in the past but I don't really see how that can be effectively managed without a lot of complicated overhead.

    If you have a suggestion for how it could be done in a low-overhead maintainable fashion, I'd be interested in hearing about it. The thoughts to date have been maybe to categorize maybe a dozen "sub-projects" that could be built stand-alone for things like all of the image processors, all of the geometry converters, the framebuffer tools, that data processors (buffer is one of these), the benchmark suite, etc.. but even that is a fair bit of effort with nearly zero incentive that directly benefits the project.

    Another thing to keep in mind, breaking the tools out would also mean breaking the libraries out as even 'buffer' utilizes our LIBBU library. Some of them could be rewritten to be more stand-alone, but then that *really* defaults the whole purpose of reusing code and sticking to consistent coding practices. Not so much a problem, but something to keep in mind.

    Cheers!
    Sean

     
  • Mark Hobley

    Mark Hobley - 2008-03-03
    • priority: 5 --> 3
    • status: pending-later --> open-later
     
  • Mark Hobley

    Mark Hobley - 2008-03-03

    Logged In: YES
    user_id=902612
    Originator: YES

    I'm not sure how much of an overhead this is. My provisional ideas are to have separate packages for brl-cad, libbrlcad, brlimgconv, brlgeomconv, brlfbtools, brldatapro, and brlbenchmark. One benefit is maybe that a change to one of the packages can be made independently of the other packages, well except for the libraries, maybe. I don't know. This is only a pie in the sky idea. I'll leave it with you. Regards, Mark.

     
  • Sean Morrison

    Sean Morrison - 2010-01-30

    I (obviously?) let this idea simmer a while and still don't see an easy way to get past the management overhead this would incur. As BRL-CAD becomes even more modular, it's certainly an idea that can be revisited later but at the moment it's not viable. Especially for the 'buffer' command, but even for sets of commands like you suggested, a lot of work would be involved and distribution becomes complicated.

    There is an intention to make the BRL-CAD Benchmark a separate (download) package to see how complex of an issue the maintenance burden becomes. It is one of the best defined and widely usable portions of BRL-CAD that applies to a very broad audience, so it'll be a good test case to see how things go.

     
  • Sean Morrison

    Sean Morrison - 2010-01-30
    • milestone: 387259 --> Major Effort
    • status: open-later --> closed-later
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks