Brian, IMO, Victor's answer is nothing but a poor attempt at an excuse. He doesn't list any technical reason what so ever. IMO, there was no reason what so ever to change the name. If the name would not be changed there would NOT be:
- Any "environment variations". - "higher priority" confusion. - "support question" doubts. AFAICT, Victor simply likes to introduce new names, for the purpose of being the name master, and nothing else, with complete disregard to compatibility. Ron On May 20, 2008, at 2:44 PM, bhays wrote: > Ron: > >> I was just annoyed >> at the lack of interest in preserving compatibility. This is not the >> first and probably not the last time we have to deal with name >> changes in Harbour sources, for no reason at all. > > I had the same first reaction, that preserving compatibility should > have more importance, but I must point out that your characterization > is incorrect. > > In all aspects, these changes are very well thought through; probably > more so than any previous changes to rddads. There are indeed reasons > for the switch; whether the reasons are strong enough to override the > desire for preserving compatibility is a judgment call. > > Remember, the goal is to simply work automatically with what the > developer has installed for development, with an option to override > for specific versions if needed. The preferred instructions would > be for users to *remove* ADS_REQUIRE_VERSION rather than change it. > > Here are some of Viktor's points: > >> Is there a technical reason why ADS_REQUIRE_VERSION couldn't stay as >> the controlling version flag rather than get replaced by a new name? > > I wanted to avoid any confusion, since the two #defines work > differently in several aspects, so it's better IMO to differentiate > by the name. One difference is that it serves a slightly different > purpose (old one is a build support "tool", new one is _only for > override_), > > and the expected content of them is also different. > Finally, if ADS_LIB_VERSION comes up in any support questions, > it's obviously targeted to the new situation, so it's easier to give > an answer. Overall, I think it's an enough deep change to merit a new > name to make things clear, and hiding this fact would rather create > more > problem than good (they will now need to install an external > package, too!). > > Now, that we're supporting ADS_REQUIRE_VERSION as well for > compatibility, > some of the above is partially solved, but the rest is still valid, > so I'd vote not to change that. > Actually I'd rather remove this compatibility #define to add more > emphasis and avoid adding up to environment variations and unnecessary > complexities (like which one is the higher priority? > why doesn't my new version of ACE gets used properly?, etc). > >> I missed out on your evolutions at the Harbour project, but >> understandably people are wondering why, if it serves the same >> purpose, the name needed to change to ADS_LIB_VERSION. > > I think, what is indeed to be considered, is whether to keep the > old name for compatibility, or drop it altogether, for the above > reasons (IMO). Notice also, that this whole set of problem only > applies > to those who actually build the library themselves, I assume most > "normal" users are using some binary distro, especially in xhb. > But I may be wrong. > > --end quote > > -- > Brian Hays > > > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
