251a3a00ee
* config/postinst.hbs
* config/global.mk
* config/bin.mk
* config/darwin/gcc.mk
* config/darwin/icc.mk
* config/darwin/clang.mk
* config/linux/gcc.mk
* config/dyn.mk
* config/os2/gcc.mk
* Trying to cleanup the harbour dynlib name situation.
Here's the plan (which is similar to what's used in contrib area):
win, wce: harbour-21[-subtype][.dll/.lib]
dos, os2: harbour[.dll|.???]
darwin:
libharbour.2.1.0.dylib
libharbour.2.1.dylib -> (symlink) [compatibility level]
libharbour.dylib -> (symlink)
*nix:
# libharbour.s?.2.1.0
# libharbour.s?.2.1 -> (symlink) [soname]
# libharbour.s? -> (symlink)
; It's possible it's broken now. Pls test linux/gcc and darwin.
'install' was not tested.
; TODO: Clean variable usage, there is some redundancy, plus
some places where current solution is not generic, f.e.
using HB_VER_*, HB_DYNLIB_BASE vs. HB_DYNLIB_NAME, etc.
* harbour/src/rtl/fscopy.c
* Reverted 2011-02-22 12:27 UTC+0200 Mindaugas Kavaliauskas
which made behavior inconsistent with rest of similar
functions like FERASE(), FRENAME(), which also don't throw
RTE if bad parameter is passed, but return FERROR()
and failure instead.
Also restored _SET_DEFAULT handling to not create a special case
compared to __COPYFILE() behavior, ia. some features like
FXO_SHARELOCK are still enabled while FXO_DEFAULT is not).
Pls rewrite it using hb_fsOpen()/hb_fsCreate() if that behavior
bothers you.