SF.net SVN: harbour-project:[15519] trunk/harbour

[dru...@users.sourceforge.net]

Revision: 15519
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=15519&view=rev
Author: druzus
Date: 2010-09-22 14:53:20 +0000 (Wed, 22 Sep 2010)

Log Message:
-----------
2010-09-22 16:52 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapicom.h
* harbour/src/rtl/hbcom.c
+ added public C function: void hb_comSetError( int iPort, int iError )

* harbour/src/rtl/hbcomhb.c
+ added PRG function: HB_COMSETERROR( nPort, nError ) --> NIL

* harbour/src/rtl/hbsocket.c
* minor formatting

* harbour/config/doc.mk
* harbour/config/postinst.hbs
* harbour/contrib/make.hbs
* do not install documentation files when HB_INSTALL_DOC=no

* harbour/config/postinst.hbs
! do not install .hbl files for core utils when HB_BUILD_PARTS=lib
+ added support for HB_INSTALL_SCRIPT executed after install step.
It allows to extract some variables set by our GNU make system,
i.e. it's used to retrieve HB_CCPREFIX in win/wince .spec files.

* harbour/package/harbour-win.spec.in
* use HB_INSTALL_DOC=no to disable DOC file installation
* generate hb{w|ce}mk2 scripts as wrappers to hbmk2 with cross
build settings so it can be easy used used by users to create
Windows/WindowsCE binaries.
Temporary solution until we will not have something more general.

Modified Paths:
--------------
trunk/harbour/ChangeLog
trunk/harbour/config/doc.mk
trunk/harbour/config/postinst.hbs
trunk/harbour/contrib/make.hbs
trunk/harbour/include/hbapicom.h
trunk/harbour/package/harbour-wce.spec.in
trunk/harbour/package/harbour-win.spec.in
trunk/harbour/src/rtl/hbcom.c
trunk/harbour/src/rtl/hbcomhb.c
trunk/harbour/src/rtl/hbsocket.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Viktor Szakáts]

Hi Przemek,

 

 * harbour/package/harbour-win.spec.in

   * generate hb{w|ce}mk2 scripts as wrappers to hbmk2 with cross
     build settings so it can be easy used used by users to create
     Windows/WindowsCE binaries.
     Temporary solution until we will not have something more general.

I'd rather think that mingw/mingwce autodetection should 

be implemented in hbmk2 than readding such wrapper scripts.

In such case -plat=win option is enough to trigger a cross-build 

and CCPREFIX/compiler can be autodetected.

If you can hammer up such autodetection logic written in .prg 

(f.e. based on current global.mk), I can attach it to hbmk2 code.

You can specify autodetect targets using logic similar to 

Windows, though maybe some more clever variation 

of FindInPath() may be better because of the many dozens 

of possible variations of mingw/mingwce on *nix systems:

{ {|| FindInPath( "i686-w64-mingw32-gcc" ) }, "mingw64", "i686-w64-mingw32-" }

Above is the detection for mingw64 on Windows, first is 

the detection code returning bool, second is the detected 

compiler name, third is CCPREFIX.

Viktor

[Przemysław Czerpak]

On Wed, 22 Sep 2010, Viktor Szakáts wrote:

Hi Viktor,

> I'd rather think that mingw/mingwce autodetection should
> be implemented in hbmk2 than readding such wrapper scripts.
> In such case -plat=win option is enough to trigger a cross-build
> and CCPREFIX/compiler can be autodetected.

I also agree that HB_CCPREFIX autodection in HBMK2 should greatly
help. Anyhow we also need synced include and lib paths so HBMK2
will not use the native host ones. Now they are set in the wrapper
script.

> If you can hammer up such autodetection logic written in .prg
> (f.e. based on current global.mk), I can attach it to hbmk2 code.

OK, I'll create it though as I said it's not enough to eliminate
wrapper scripts.

best regards,
Przemek

[Viktor Szakáts]

Hi Przemek,

 

I also agree that HB_CCPREFIX autodection in HBMK2 should greatly
help. Anyhow we also need synced include and lib paths so HBMK2
will not use the native host ones. Now they are set in the wrapper
script.

> If you can hammer up such autodetection logic written in .prg
> (f.e. based on current global.mk), I can attach it to hbmk2 code.

OK, I'll create it though as I said it's not enough to eliminate
wrapper scripts.

Thank you. So we should also agree on a multitarget dir 

layout for *nix systems. Any *nix/Linux standard for this, 

or anything you propose?

[ my proposal is {/usr/lib/harbour/}plat/comp/* ]

Viktor