I believe the intent was only towards the src/ sub-hierarchy as there are other dirs like doc and misc that similarly need to exist. I'd expect cmake modules to live at the top-level similar to the m4 dir with autotool setups.
On Apr 17, 2009, at 3:15 AM, Ralith wrote: > 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 ------------------------------------------------------------------------------ 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
