So, in case there is no objection, I'd like to start making some changes regarding that. Pls be warned that I may break things in the process due to mistakes or because I don't fully oversee some configuration scenarios. So be patient.
Few thoughts on the process: - pcre and zlib will be removed from Harbour dynlibs. On *nix they will be linked to system libs by default, otherwise they will have to be linked statically to apps (not to dynlibs - at least that's how I see it now). This will need hbmk2/hbmk modifications. - external dir will have to be moved up in build order, so utils can be created when using local zlib/pcre builds. - for bcc an additional package will have to be detected. I'm not at all sure if support for this built-in bcc regex is worth all the effort (maintenance/testing). So I'd like to get opinions in dropping it. [ We have the real pcre there for bcc. ]. - above changes will most probably cause that we drop HB_EXT_ZLIB (this will be the default when available), HB_PCRE_REGEX (replaced by HB_INC_PCRE) and HB_POSIX_REGEX (replaced by HB_INC_PCRE=no on *nix systems). - HB_INC_ZLIB will be added to control zlib location, with the option to force local one. Here 'no' may not be a valid option, as we need something for core. - include/hbzlib.h will be dropped. Replaced by direct #include <zlib.h> lines and appropriate -I options added on build level. - Internal pcre include logic to be change like above. Any comments on these? Brgds, Viktor On 2009.09.10., at 01:02, Viktor Szakáts wrote:
Hi All, There is a pending item on my TODO list to move hbzlib and hbpcre sources under /external tree. At the same time the detection of externally available versions could also be added, and possibility to override them with usual HB_INC_* vars also. It's probably healthier to use these on *nix systems anyway. The other benefit would be that we'd hold all 3rd party code in one easy to identify spot, which makes them easier to manage (update/config/strip/distribute). One consequence is that they'd have to be renamed to their original lib names (dropping 'hb' prefix). Plus some additional hbmk[2] tricks will be required. Is there any reason this move cannot or shouldn't be made? Or some issues to be aware of? Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
