169631527c
* contrib/hbhttpd/log.prg
* contrib/hbtip/log.prg
* contrib/hbziparc/ziparc.prg
* src/rtl/hbdoc.prg
* src/rtl/hbi18n2.prg
* src/rtl/memvarhb.prg
* src/rtl/tlabel.prg
* src/rtl/treport.prg
% use HB_FNAMEEXTSETDEF() instead of manual logic.
it also fixes RTEs in hbziparc when passed non-string
filename to nearly any of its APIs.
* utils/hbi18n/hbi18n.hbp
* missed -shared enabler in .hbp
* utils/hbmk2/Makefile
* utils/hbmk2/hbmk2.hbp
+ enabled -shared build for hbmk2
* utils/hbmk2/hbmk2.prg
% consolidated .hbc finder logic
% moved 'hbmk' structure initializations to subfunctions
+ added Harbour installation autodetection for hbmk2's
runner mode. It's copy-paste code yet.
+ added automatic include path configuration in hbmk2's
runner mode. It means that now #require-d extensions
will have their include paths setup, so their header
will be found, so they can be used now.
; I more and more see it a reality to integrate hbrun
functionality into hbmk2. #require logic needs
much of hbmk2's facilities, and hbmk2 already has
basic runner capabilities. Contrib libs (and plugins)
will all have to be loaded dynamically in such case,
but since it works well, it should not be a problem.
Finally hbmk2 can be the utility that runs scripts
dynamically and also able to build an exe from them,
using the exact same source code, without any external
configuration, if the source code provides "#require"
clues. All it needs is both dynamic and static versions
of extensions (=contribs or addons).