Delayed response but I put some more thought into this problem recently...
On Tuesday, July 14, 2009, at 09:24AM, "Daniel Roßberg" <[email protected]> wrote: >Hi, > >There were put a lot of effort into hiding any version number define >and/or constant from the user. Now I'm in doubt if this was wise. The core issue I'm concerned with is making it difficult for version-specific compile-time code to be written. If we can find a run-time solution, that should be fine. >I ran into the problem that the BRL-CAD version present at link time >is another than at run time. I.e. I upgrade the BRL-CAD library by >replacing the brlcad.dll and keeping the program executable. This may >lead to compatibility problems. To deal with this kind of problems it >would be good to have the possibility to memorize the BRL-CAD version >at build time in the executable. "Our" executables already have the ability to be aware of the BRL-CAD version they are part of via the brlcad_version() and brlcad_ident() functions. Given they are static, they will get compiled into whatever front-end binary or back-end DLL that calls them (which is of course intentional). Each library has a LIB_version() function which could be compared against the library versions to determine compatibility. Granted, the version functions presently return strings, but that could be separated from the number itself similar to brlcad_version()/brlcad_ident() for each library. >Is there already a practicable solution for this problem based on an >installed BRL-CAD? Yeah.. the issue then remaining is that brlcad_version.h is not presently installed and the geometry engine (coreInterface, GE, and GS included) are written as if they were some 3rd-party developer using the public API. The solutions that immediately come to mind are: a) Install brlcad_version.h (along with include/conf) making it similar to common.h (i.e. not owned by any library except libbrlcad). I'd want to undef the version variables so they're not compile-time accessible. We could also install brlcad_version.h without include/conf, but Windows becomes a little problematic. b) Treat the engine like other BRL-CAD code, requiring a 'brlcad' source tree so it can get at brlcad_version.h. The downside of this is of course the benefits of API separation and loosely coupled development. The benefit would be simplified build integration and access to private API. >At the moment I'm creating my "private" brlcadversion.h to be >distributed with the brlcad.dll developer package. Does this include the include/conf files, or do you just create your own header with the values you need? Cheers! Sean ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
