On Fri, Nov 28, 2014 at 11:25 PM, Michael Barton <michael.bar...@asu.edu> wrote: > Markus explained that this is for libgis only. That seems OK to me. My > concern (based on the error message generated) is that this would block any > module built against any version older than the current one being run. That > seemed an unnecessarily strong check, but apparently not what is happening.
Actually this should happen for modules. If libgis or any other lib changes in trunk, all modules using libgis and/or the respective lib need to be recompiled. There is no reason to assume that different revisions of trunk are binary compatible, it's trunk. Markus M > > Michael > ____________________ > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Head, Graduate Faculty in Complex Adaptive Systems Science > Arizona State University > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu > > > > >> On Nov 27, 2014, at 10:40 AM, Glynn Clements <gl...@gclements.plus.com> >> wrote: >> >> >> Michael Barton wrote: >> >>> Why do we need to do this? >> >> Because getting developers to agree to maintaining a stable ABI (then >> ensuring that actually happens) appears to be beyond our capabilities. >> >> Probably the most common (and certainly the most obvious) example of >> incompatible changes (and the trigger for adding that check in the >> first place) is adding new enumerants in the middle of "enum STD_OPT" >> (the constants passed to G_define_standard_option()), resulting in all >> subsequent enumerants getting new values, resulting in the module >> suddenly accepting completely different (and usually completely >> nonsensical) options. >> >> -- >> Glynn Clements <gl...@gclements.plus.com> > > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
