* utils/hbmk2/hbmk2.prg
+ will now add lib/3rd dir to the link commands, so
unicows lib will be found in uninstalled Harbour SVN
source tree.
* contrib/make.hbs
* contrib/hbpost.hbm
+ automatically enable unicows support for contribs, if available.
- deleted support for undocumented __HB_BUILD_WINUNI envvar
* config/global.mk
* config/rules.mk
- deleted support for undocumented __HB_BUILD_WINUNI envvar
* package/winuni/mpkg_win_uni.bat
* package/mpkg_win_nightly.bat
- deleted special support for unicows libs for nightly
and official releases, along with HB_DIR_UNICOWS envvar.
Now these libs are included in all builds.
* config/win/global.mk
+ automatically enable unicows support for core, if available.
* config/win/xcc.mk
* config/win/icc.mk
* config/win/mingw.mk
* config/win/pocc.mk
* config/win/bcc.mk
* config/win/msvc.mk
+ added support for SYSLIBPATHS. (used by unicows support)
! fixed bcc dynlib link command missing libpaths.
; NOTE: watcom unicows support is missing, as it needs
special tricks due to missing separate libpath option
in this compiler/linker.
* config/wce/mingwarm.mk
* config/wce/poccarm.mk
* config/wce/msvcarm.mk
* synced with config/win files
+ config/libbin.mk
+ added rule to install pre-built binary libs.
(for unicows libs)
* Makefile
+ lib/3rd
+ lib/3rd/win
+ lib/3rd/win/mingw
+ lib/3rd/win/mingw/Makefile
+ lib/3rd/win/mingw/libunicows.a
+ lib/3rd/win/mingw/libunicows_license.txt
+ lib/3rd/win/bcc
+ lib/3rd/win/bcc/unicows_license.txt
+ lib/3rd/win/bcc/unicows.lib
+ lib/3rd/win/bcc/Makefile
+ added locally hosted unicows runtime/implibs from:
http://libunicows.sourceforge.net/ by author Vaclav Slavik.
With these libs, it's possible to use UNICODE builds
with both MS unicows.dll and opencows .dll on legacy
Windows-system (Win9x).
These libs will be installed to Harbour core lib directory,
and also used from lib/3rd directory, if they are available.
I've uploaed mingw and bcc libs because these are used
nearly exclusively by users, but they are also available
for older msvc, watcom, dmc and lcc compilers. I don't
think it's worth the extra size to support Win9x using
these legacy compilers, anyhow they can be added easily
if needed (except watcom, which requires more work).
; These changes mean three things:
1. Harbour now has only one build mode on Windows: UNICODE
This will greatly simplify coding and testing and will
allow to focus much better on what's important. It also
allows to drop lots of dual code dealing with separate
UNICODE and non-UNICODE branches.
2. Harbour default builds will now run on Win9x (currently
when using mingw or bcc compilers), though UNICOWS.DLL
is now required. See INSTALL how to get this free .dll
from MS. This also means that Harbour can now theoretically
by built on Win9x systems (I didn't try).
3. Harbour users can create UNICODE builds compatible with
Win9x, by simply adding -lunicows to their .hbp projects.
No extra installation is required.
+ package/harbour.rb
+ experimental (and untested) Homebrew formula
* debian/dirs
* debian/rules
+ added contrib dir (untested)
* utils/hbmk2/hbmk2.prg
* autodetect contrib/addons dirs at
/usr/local/share/harbour/ and /usr/share/harbour/
* config/global.mk
* changed contrib location on *nix systems to <root>/share/harbour/contrib
unless the <root> is /opt/harbour.
* package/winuni/mpkg_win_uni.bat
- deleted windows-only contrib specific file installation
procedure. now done by contrib/make.hbs.
; it also means that contrib-specific public files are
now included in non-unified installation packages,
created using HB_BUILD_PKG=yes.
; TODO: modify *nix package creation scripts to include
/opt/harbour/contrib in the package.
* config/global.mk
* INSTALL
* changed HB_INSTALL_IMPLIB default to 'yes'. This means
that now the implibs for 3rd party .dlls will be included
in install packages, including the nightly/stable releases.
This is theoretically wrong solution and bad practice, but
to me real life shows that users don't have a clue about
implibs and how to generate them and it also requires users
to build Harbour themselves if they want to use any of the
many libs with implib dependencies, instead of being able
to use binary releases.
One big WARNING applies (quote from INSTALL):
"Also note that the generated implibs will require .dlls
compatible with the ones used at build time."
IOW you must be using the same (or binary compatible)
.dll as was used at built time. If you use something else,
you still will have to generate the implib yourself or
change your .dll version according to above.
[I hope Marek Paliwoda doesn't mind.]
* contrib/hbrun/headers.prg
* utils/hbmk2/hbmk2.prg
* changed #include filename references to _CASE-SENSITIVE_. This
is to ensure and enforce that .hbs scripts and hbmk2 plugins are
created in portable form so f.e. once developed on a win
system, they won't crash on a *nix system.
INCOMPATIBLE: Change all your #include references to exactly match
casing of the filename. For Harbour headers, this
means plain lowercase, so f.e. '#include "FileIO.ch"'
is wrong, '#include "fileio.ch"' is right.
* config/global.mk
* minor
* contrib/make.hbs
+ added installation support of contrib specific public files
(.hbc, .hbs, local headers, .def files, readmes and tests)
* config/global.mk
* set install destination for contrib specific public files to
<root>/contrib for non-*nix and /opt/harbour/contrib for *nix
systems.
* utils/hbmk2/hbmk2.prg
* changed HB_INSTALL_CONTRIB to HB_INSTALL_ADDONS
F.e.:
export HB_INSTALL_ADDONS=/usr/local/share/harbour/contrib:/usr/local/share/harbour/addons
* contrib/hbcups/hbcups.hbc
* added libs for OS/2. As suggested by David Arturo Macias Corona
* config/global.mk
! added missing $(HB_HOST_BIN_EXT) in wildcard command used of
user HB_CCPATH/HB_CCPREFIX verification.
(in line 960)
* harbour/src/macro/macrolex.c
! added missing YY token assignment I removed by mistake in last
macrolex modification.
This modification fixes problem with extended string decoding
by macrocompiler.
* harbour/config/global.mk
! added missing $(HB_HOST_BIN_EXT) in wildcard command used of
user HB_CCPATH/HB_CCPREFIX verification.
* include/Makefile
+ include/hbstrict.ch
* contrib/hbpost.hbm
+ added experimental -u+ header to catch some common code style
problems. currently IF() is caught, but it interferec with std.ch
hbsix.ch and possibly more, so it's not enabled
* config/global.mk
* src/dynlib/2nd/Makefile
* src/dynlib/Makefile
* secondary harbour dynlib is now enabled by __HB_BUILD_DYN_2ND=yes
* renamed secondary harbour dynlib to harbour2*
+ it's now possible (again) to build harbour .dll in ST mode by
using __HB_BUILD_DYN_ST=yes. if used together with __HB_BUILD_DYN_2ND=yes,
the secondary dynlib will be MT. (pls note the secondary dynlib
is never directly used by hbmk2, so it's there for mere build convenience
only)
* contrib/hbxbp/xbpmenubar.prg
* contrib/hbxbp/xbprtf.prg
* contrib/hbxbp/xbpfiledialog.prg
* contrib/hbxbp/xbpprintdialog.prg
* contrib/hbxbp/xbpscrollbar.prg
* contrib/hbxbp/xbpprinter.prg
* contrib/hbxbp/xbpdataref.prg
! IF() -> IIF() (with the help of hbstrict.ch)
* contrib/hbformat/hbfmtcls.prg
! fixed mistakenly changed '==' to LEFTEQUAL() in prev commit
* utils/hbmk2/hbmk2.prg
+ added mingw-w64 autodetection on *nix
* doc/xhb-diff.txt
! typos
* config/global.mk
+ added mingw-w64 autodetection on *nix. build with 'make HB_COMPILER=mingw64'
! supposedly fixed wce/mingw (intel) comp autodetection
* had to change CC*/compiler autodetection on *nix cross builds
and since this file is black magic, fallouts are possible.
pls test it (disc: I'm no heavy linux user, you've been warned)
; NOTE: win/mingw64 build on linux results in broken exes (400+ hbtest failures
and even the percentage of failure is calculated as 0.0%),
most likely due to these (which may even be mingw64 bugs):
../../../hbarch.c: In function 'hb_put_ord_ieee754':
../../../hbarch.c:181: warning: 'iExp' may be used uninitialized in this function
../../../hbarch.c: In function 'hb_put_ieee754':
../../../hbarch.c:114: warning: 'iExp' may be used uninitialized in this function
../../../hbstr.c: In function 'hb_numRound':
../../../hbstr.c:500: warning: statement with no effect
../../../hbstr.c: In function 'hb_numInt':
../../../hbstr.c:525: warning: statement with no effect
../../../hbstr.c:519: warning: 'dInt' is used uninitialized in this function
../../../hbstr.c: In function 'hb_numRound':
../../../hbstr.c:512: warning: 'doComplete5i' may be used uninitialized in this function
../../../hbstr.c: In function 'hb_numDecConv':
../../../hbstr.c:514: warning: 'doComplete5i' may be used uninitialized in this function
../../../hbstr.c:396: note: 'doComplete5i' was declared here
In file included from ../../../hvmall.c:105:
../../../itemapi.c: In function 'hb_itemStrBuf':
../../../itemapi.c:2329: warning: 'dDig' may be used uninitialized in this function
* INSTALL
- Deleted HB_BUILD_WINUNI option. It's not documented
option anymore. Pls don't use it. Use UNICOWS solution
if you need Win9x/ME support. Pls also note that _building Harbour_
on Win9x/ME systems is deprecated (as it is only possible
to build Harbour in non-UNICODE version in such scenario).
* config/global.mk
- Deleted some built-in build names which only differed
in WINUNI setting.
* config/global.mk
! Fixed regression for win/wce systems after recent dynlib changes.
On these systems the referenced lib name should always contain
the version number.
* 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.
* config/global.mk
* src/dynlib/Makefile
+ src/dynlib/2nd
+ src/dynlib/2nd/Makefile
* Changed so that _HB_BUILD_DYN_ST=yes now creates a separate,
secondary dll in ST mode, called harbourst/harbours.
- src/dynlib/mt
* src/dynlib/Makefile
* src/vm/maindllp/dllpcode.c
* package/winuni/mpkg_win_uni.bat
* package/winuni/mpkg_win_uni.nsi
* utils/hbmk2/hbmk2.prg
* config/postinst.hbs
* config/global.mk
* config/bin.mk
* Changed to have only one harbour dll, and this one with MT support.
This means the old MT mode dll named harbourmt/harbourm is no more
and the old ST mode dll vanished also. This will result in much
cleaner layout of Harbour binary tree, smaller distribution size,
and unambigous dll tree when linking an app with dll multiple
components (f.e. contribs).
If someone wants to build an ST mode harbour dll, she can use the
internal build-time option: _HB_BUILD_DYN_ST=yes
; Please test.
; TODO: Do a final cleanup on internal variable names to not have "ST" in them.
* config/global.mk
* config/rules.mk
* contrib/hbpost.hbm
* INSTALL
+ Renamed HB_BUILD_UNICODE to HB_BUILD_WINUNI.
Reasons many-fold, first it makes it clear this is a Windows
only setting, second it makes room for future UNICODE
setting which may mean a native UNICODE Harbour HVM,
third is to try to clear up the wide misunderstandings
surrounding this setting (several users thought this
will enable general UNICODE support in Harbour).
+ Extended/changed description of option HB_BUILD_WINUNI,
explaining its purpose better, giving more precise details
for WinCE builds and builds on Win9x/ME hosts.
; INCOMPATIBLE: If you use this setting, rename it on
your system. Note1: You don't have to set this
when doing WinCE builds (it's ignored).
Note2: Try UNICOWS, instead of overriding
this setting. It works.
* package/harbour.spec
* package/harbour-win.spec.in
* package/harbour-wce.spec.in
* include/hbver.h
* config/global.mk
+ Changed version number to:
2.1.0beta3 (from 2.1.0beta2)
* contrib/gtwvg/gtwvg.hbc
! Typo.
* contrib/gtwvg/tests/wvgactivex.prg
* Eliminated WITH OBJECT. Now Harbour doesn't
use this statement except in test code.
* config/global.mk
! HB_INSTALL_PREFIX now defaults to /opt/harbour (instead of /usr/local)
on darwin systems. (not tested)
/opt/local is for MacPorts, plus /opt/harbour is the location
hardcoded into hbmk2 for .hbc autofind, so I opted for the latter.
* contrib/hbhttpd/core.prg
* Formatting.
* contrib/hbexpat/expat/expat.hbp
* contrib/hbexpat/hbexpat.hbp
* contrib/hbexpat/hbexpat.hbc
* Minor cleanups.
* contrib/hbexpat/tests/tohash.prg
+ Added HB_HKEEPORDER( , .T. )
* external/Makefile
* config/global.mk
* INSTALL
- Deleted central option to control external lib building:
HB_EXTERNALLIBS
! Also deleted one reference to HB_EXTERNAL_ADDONS, which has
been removed earlier.
+ external/minizip/minizip.hbp
+ external/minizip/minizip.hbc
+ external/sqlite3/sqlite3.hbc
+ external/sqlite3/sqlite3.hbp
+ external/bzip2/bzip2.hbc
+ external/bzip2/bzip2.hbp
+ external/libhpdf/libhpdf.hbc
+ external/libhpdf/libhpdf.hbp
+ Added experimental hbmk2 make files for
foreign code which is used solely by contribs.
* src/pp/ppcore.c
! Fixed regression in 2010-11-01 16:42 UTC+0200.
Forgot to set value for __PLATFORM__* macros.
INCOMPATIBLE: So far the value returned by __PLATFORM__*
macros were the version part from the string
also returned by OS(), but only in non-cross
platform situations. Now they are defined
without any value, which means now the returned
value is consistent regardless of build-situation
and OS version. If you relied on this feature,
change your code to extract OS version from value
return by OS() function.
* src/vm/mainwin.c
% Do not include windows header.
* src/vm/cmdarg.c
- Undone some (innocent) part of patch in 2010-11-01 13:53 UTC+0200.
* INSTALL
* Moved around cygwin inside example section.
* src/vm/Makefile
* src/vm/mainwin.c
* src/vm/hvm.c
* src/vm/cmdarg.c
* src/vm/vmmt/Makefile
* utils/hbmk2/hbmk2.prg
* config/global.mk
* config/cygwin/global.mk
+ Cygwin related patch from Tamas Tevesz.
- Fixing cygwin dynamic lib name
- Dynamic lib linking
- defining __PLATFORM__CYGWIN in cross-platform builds
* src/rtl/dateshb.c
+ tests/dttest.prg
+ HB_DATETIME() got new, optional nYear, nMonth, nDay, nHour, nMinute, nSecond, nFragment
parameters. If passed, it will return date or timestamp based on passed parameters
instead of current timestamp.
Based on initiative and code by Carlos Bacco. Thank you!
* contrib/hbsqlit3/hbsqlit3.c
- Reverted UTF8 patch in 2010-11-01 00:05 UTC+0200.
+ Replaced above solution with transparent one, using
Str API usage and extended it for all places where UTF8
strings are expected or returned by sqlite3 API.
Please test. This clears an old TOFIX.
+ Added TOFIX for raw pointer usage.
* contrib/hbqt/qtgui/g/QApplication.cpp
* contrib/hbqt/qtgui/qth/QApplication.qth
! Fixed to wrap one declaration in HB_EXTERN_BEGIN/END.
