ADS adds functions and features on incremental releases, so the major-version-only usage of ADS_REQUIRE_VERSION was problematic in accurately isolating code to match libs and dlls.
In the Harbour project, Viktor created a new more accurate ADS_LIB_VERSION to handle 3 or more digits of version#s to fix this. In this rddads rewrite, attempts are made to translate ADS_REQUIRE_VERSION to the equivalent ADS_LIB_VERSION to minimize conversion growing pains, but the recommendation is for users to NOT DEFINE A VERSION AT ALL and let the build mechanisms figure it out automatically. (I have not yet translated that projects build/batch files for xHarbour as theres a dependence on an integrated build setup for Harbour thats different than what we have). As part of his "auto-detecting", his proposal is that developers always have a real installation of the acesdk (the folder created by the installers distributed by ADS), and the (x)Harbour build will look there for headers and to determine dll versions and even create ace32.lib. A #define can be used to specify this folder, so you can easily switch between versions as needed. This is IMHO a much more sane concept than what evolved over the years, with various ace32.lib files floating around. It also means the ace.h for each version stays in that ADS folder and the cvs need not carry it any more. BUT requiring users to change their setup to be able to build rddads may create some strife, so we may want to rework I some. Here are more details in my email conversation with Viktor: > For the build process, is the idea that if the old #define is in place > it will build like it always did, or will it require developers to > create the aceapi folder? In the context of Harbour, the non-GNU build processes expect ADS_DIR to point to the dir where ace.h, ace32.dll and ace32.lib is installed. This is X:\ads\acesdk\ for an officially installed ACE package, but, as long as these files are found there, there should be no problem, in fact the most important is ace.h, the rest is not fatal, but if not found, users will have to deal with ace32.lib creation (see later). This requirement is different for non-GNU make_gnu.sh, where ADS_INC should point to the header dir (so it should point to the same dir as ADS_DIR. This difference is unfortunate, but we're not always pulling to the same direction), and also different for the GNU make system, where - I guess - ace.h should be somewhere in the INCLUDE path. All the above is independent from the way ADS_LIB_VERSION, or ADS_REQUIRE_VERSION are defined. ACE files are always looked for by the above logic. > most users don't actually do an install from ADS but have acquired the > needed files and put them in the various lib or other folders. There > might be a lot of pushback if this update *forces* people to change > their setup--and if it does we should try to make it obvious what they > need to do so they don't have to go to the NG. They will definitely need to change a bit, as ace.h is not distributed anymore with rddads. This move was debated by some, but I've found it very unhealthy to maintain a modified ace.h. Now rddads is working like the rest of the contribs, so that external package stuff is indeed external. Another change is the automatic creation of ace32.lib, out of ace32.dll. This happens only for non-GNU B32/VC make systems, and for VC it's now copying the .lib distributed with the package rather than generating it. So, in other words ace32.lib is only created for non-GNU B32 builds. Some expected user reports will be mismatched .lib and .dll resulting in unresolved functions at runtime. This is usually caused by different version of .dll installed in app or system32 path, than the one at ACE_DIR. -- end quote Its my recommendation that we jump in and go with it, and tweak as needed. But I have Zero experience with any non-Borland build environments. It would also be good to hear from those xHarbour developers who also use the Harbour project and ADS (if there are any listening): How well has the transition worked for you? -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/xharbour-developers
