If cmake is to be standardized on throughout, the reorganization should probably include a directory specifically for cmake modules, which tend to be reusable. For example, g3d currently uses a LibFindMacros module which simplifies searching for dependencies, and includes several Find* modules to implement dependency search in a reusable way for a variety of packages. Sharing these files between projects would reduce redundancy in both development efforts and the repository itself.
Christopher Sean Morrison wrote: > Kudos and thanks to Dave for taking the initiative. Great work, especially > towards integrating the various efforts. > > To affirm a few design intents and organizational motivations, the purpose > and intent of the 'rt^3' module was (and still is) to be the foundation for a > new "unified" framework that would sit on top of the "heart" of BRL-CAD -- > i.e., all the code in the 'brlcad' module. Moreover, when the 'rt^3' module > was started, we weren't putting C++ code into the 'brlcad' module and given > the new unified framework's design was planned to be implemented OO/C++, it > made (and still makes) sense to keep the work separate. > > As for the suggested restructuring, the only issue I see is with the > applications and the mix of conventions. For example, application-wise, I > don't see a difference between the 'g3d' work and 'iBME' design and the > original 'rt^3' effort. I don't think we should keep the original 'rt^3' > name, though, and 'g3d' conflicts with the name of another popular project. > So we can just call it iBME for now. But!... > > This new integrated/unified environment is going to eventually be installed > as the single application front to BRL-CAD, so it could also just be called > 'BRL-CAD' or 'brlcad' as that is what the binary itself will eventually > become. > > All of the binaries and commands of functionality in the core module > effectively become plugins and foundation for the new system. > > Few other comments to think about (not all of which affect the restructure > much): > > * the 'date' directory is a build-system stamping tool (that applies to all > products, not just GS). It was a means to guarantee that all application > could accurately report their build date even through relinks. The 'brlcad' > module does this much better. > > * the 'lib' prefixes can go away. That's a mix of conventions -- the > sub-functionality should 'em or not, but not mixed. Common practice for > installed libraries to use that convention, but thus far the only library > we're talking about keeping as an API is the GE (which may be a lib or > collection of libs). > > * 'coreInterface' is effectively a combination of what was libGeometry and > libRaytrace. The Interface 'suffx' is implicit as part of the GE. Should > probably become either 'Core' or 'Geometry' or simply be the contents of GE. > > * interface and integration tests are relatively low-maintenance. > comprehensive unit tests are very expensive. non-comprehensive unit tests > tend to decay. GE public API could benefit greatly from unit tests. GS > network protocol could benefit greatly from interface tests. GUIs tend to be > pretty unstable for anything more than integration tests. > > * cmake is good. Kudos to Ralith for fixing the 'brlcad' module pkg-config > files and getting the new gui cmake build files to use it! > > Cheers! > Sean > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
