* utils/hbmk2/hbmk2.prg
* Changed ${hb_self} macro to ${hb_dir}
+ Added ${hb_name} macro which translates to the container
filename (so f.e. in hbwin.hbc it will be "hbwin")
+ Added "late-evaluation" macros in libpaths= lists,
when looking for .hbc files. Late eval macros are marked
with %{}. This feature means you can setup
'libpaths=contrib/%{hb_name}' and when looking for
'hbwin.hbc', it will look for it in contrib/hbwin dir.
* libpaths/-L values will not be checked for existence before
adding them to internal lib list.
; All this means that it's now possible to setup contrib
libs and headers in their own directory while keeping the
"zero-conf" work environment. IOW contrib libs and directories
don't need to "pollute" central lib/header dir. This also
means that we can lift lots of restrictions regarding
naming, since only lib name needs to be unique, headers
don't (it's still good practice though since one users
may want to use both contribs at the same time), they
also don't bother those users who aren't using them. This
system also makes it very easy to add 3rd party libs to
the contrib dir. So in this sense it's basically a fully
open "plugin" system for any libs.
It's very easily possible to add 'examples', or 'extras'
subtrees to libpath also.
From the user side, it looks like this (without any extra
configuration or any path specs):
> hbmk2 myprogram.prg hbwin.hbc hbct.hbc
; QUESTION: Where such contribs (with libs and headers)
could go on a *nix system? While developing
above stuff I had the unified Windows installer
in mind, but it would be good to adapt these
on *nix systems, too.
+ contrib/xpp/xpp.hbc
+ Added .hbc file for xpp lib.
90a6cfab37