Tom,
Minor API changes such as the one you encountered should be expected
across minor revision numbers (7.12 vs 7.14). The doc/
deprecation.txt file describes changes that are considered "minimally
impacting" as:
"Minimally Impacting: If a change to an interface has a suitable and
completely equivalent alternative, the change is deemed to be
"minimally impacting" and can be made during any minor release.
Examples of such changes include renaming an interface, reordering
parameters, adding new parameters to an interface for previously
implicit or restricted behavior, and removing unused parameters.
Basically, the impact can usually be considered minor if a simple
regular expression search-and-replace is all that is needed."
The intention is to avoid stagnating the API, so that it may be
adaptively evolved and improved. Maintaining API portability is of
course of paramount concern, but the APIs (of all of our libraries)
have lots of room for improvement, inconsistencies, poor naming
choices, and more. So when there's a change, such as the unused
resource pointer on rt_db_free_internal(), the deprecation process
allows it to be fixed during a minor release.
Version numbers were specifically hidden from headers to prevent
developers from making compile-time affordances in code for multiple
versions of API. Exactly what it sounds like you're trying to do to
work around the signature change.. :) Those "#if version ==
whatever" compile-time checks are certainly convenient and simple but
they slow down API evolution detrimentally and cause added migration
burdens for all involved down the road.
Is this a case of looking for a technical solution to a sociological
problem? If you're collaborating with someone on a bit of code, it
sounds like you both should be on the same version (at least the same
minor version). What is keeping your teammate from upgrading? Or
why are you using the latest release instead of the version they're
using?
That said, if I were in your situation and HAD to figure something
out and they could not upgrade, then my solution would probably be to
manually keep a sed script on hand that converts the code to the new
version on my end. All of the minimally impacting changes should be
converted with a simple regular expression (the regex for the
rt_db_free_internal() change is in doc/deprecation.txt). If that was
too much of a burden, I could always wrap the latest code in some
arbitrary define that I pass as a CPPFLAG when I build.
Cheers!
Sean
On Feb 1, 2010, at 4:45 PM, Tom Browder wrote:
I am now running into a situation where my development system is using
the latest release of BRL-CAD (7.16.4) and my remote team mate is
using an older one (7.12.6) and some function signatures have changed.
Specifically,
void rt_db_free_internal(struct rt_db_internal *ip, struct
resource *resp);
became
void rt_db_free_internal(struct rt_db_internal *ip);
and g++ 4.4.3 doesn't like that. I have found no clean way to use a
compile-time cpp macro to distinguish the two versions but would
appreciate any ideas. I know my team mate needs to upgrade, but that
isn't in the cards at the moment.
Note there is a PACKAGE_VERSION defined as a string but I don't think
you can use that at compile time (at least I haven't found a solution
looking at the cpp manual).
I think we need something like gcc and others use:
#define BRLCAD_MAJOR_VERSION 7
#define BRLCAD_MINOR_VERSION 16
#define BRLCAD_PATCH_VERSION 4
From the cpp manual (4.4.3), gcc defines three macros
__GNUC__ // major version
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
and they show a couple of ways to test for a specific version. I like
this method:
#define GCC_VERSION (__GNUC__ * 10000 \
+ __GNUC_MINOR__ * 100 \
+ __GNUC_PATCHLEVEL__)
/* Test for GCC > 3.2.0 */
#if GCC_VERSION > 30200
or BRl-CAD could just take the easier, direct route:
#define BRLCAD_VERSION 71604 // allows up to 100 minor
versions and 100 patch levels for each major version
For the moment I will use a kludge macro until I hear the magic
solution.
Thanks.
-Tom
Thomas M. Browder, Jr.
Niceville, Florida
USA
----------------------------------------------------------------------
--------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in
the business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone
call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
