Hi Przemek,
On 2010 Jan 26, at 12:31, Przemysław Czerpak wrote:
>>> TOFIX: -xhb shared mode uses 'harbour' instead of 'xharbour' library
>>> and 'hbmainstd' instead of 'mainstd'
>>> TOFIX2: -gui switch in -xhb mode cause compile time error:
>> For me the problem with TOFIX and TOFIX2, is that
>> I have no idea what names are used for dynlibs in xhb.
>> If you can tell me about it, I can apply the fixes.
>
> Thank you very much.
> I've just look closer at current xHarbour CVS and it will not be easy
> to make sth with it.
> In current xHarbour CVS code MinGW build uses 'xharbour[mt]-1.2.1'
> and in the earlier versions it was without version number 'xharbour[mt]'.
> But non GNU make windows builds create 'harbour.dll' !!! instead of
> 'xharbour.dll'. Looks that first xHarbour developers should clean it
> and we should not touch it now.
Not great.. anyway something I have suspected when observing
xhb at the time I added -xhb flag. To make things worse the
commercial demo edition of xhb (this the only xhb binary build
on my system), it's named 'xHBdll.dll'. I see no separate MT
version around, although there seems to be a debug (?) version
by the name 'xHBddll.dll'.
I'll add the versionless .dll names for mingw targets for now.
>> Also, what is the equivalent of hbmainwin in xhb?
>
> xHarbour does not have such library at all. It only has 'mainstd' in
> MinGW builds.
> Current xHarbour versions seems to have also some additional libraries
> for dynmaic code but I do not know what is their exact job. They try to
> overload some of HVM public symbols and such operation is illegal for
> most of linkers so I guess it's a hack only for some chosen windows
> compilers. I cannot say more without investing more time in checking
> the xHarbour code and I have serious doubts that it's possible to find
> xHarbour developer who can explain what exactly this feature should do
> and can clean it to work with all linkers so I think we should not touch
> it too.
Okay. I'll update it for MinGW for now.
I'm not very optimistic about the rest, as it was
a huge job to make this consistent across all targets
in Harbour (also for .dlls).
> BTW I have also some questions about filters in hbmk2 script files.
> Does -help output describe all condition variables?
No, a few ones are missing. I'll add them. Plus envvars
can also be used, which is not mentioned in help (but
I will skip this for now, it's very niche feature).
You can find all recognized filter keywords in function
'hbmk_KEYW()' @ hbmk2.prg.
> Is it possible to use or add conditional switch like {shared} in .hbc files?
> How exactly the conditions are processed? Can they be located anywhere in
> the line and when evaluate to false they disable whole line?
> What will happen if I use more then one condition in single line,
> i.e. -o{win}win{bcc}bcc ?
Filter affects the whole option regardless of where you
place it. Multiple filters are not supported, so only the
first one will be parsed as such.
To achieve the above you can use this solution:
-o{win&!bcc}myname-win
-o{win&bcc}myname-win-bcc
> Maybe it's be possible to create .hbc file which will allow to use
> different xHarbour versions without touch hbmk2 code.
It most probably is possible, I've created such .hbc file
for MiniGUI: contrib/utils/hbmk2/examples/minigui.hbc
(now it's also in official MiniGUI distro, so this one
can be deleted now):
---
# Copy this file to 'hmg extended' root dir and include it
# in hbmk2 command line to build an app:
# > hbmk2 test.prg C:\minihui\minigui.hbc
{win}incpaths=include
{win}libpaths=lib
{win&!xhb}libpaths=harbour/lib
{win&xhb}libpaths=xLib
{win}gt=gtgui
gui=yes
# core
{win}libs=minigui
# core #2
{bcc}libs=cputype propgrid propsheet tsbrowse WinReport
# core (binary)
{bcc}libs=dll hbprinter miniprint TMsAgent
# Harbour contribs
{win}libs=hbmzip
{win&!xhb}libs=hbwin
# system
{win}libs=vfw32
---
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
