diff --git a/ChangeLog.txt b/ChangeLog.txt index 9cb4faecbb..04fe5952dc 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -10,6 +10,27 @@ * Change, ! Fix, % Optimization, + Addition, - Removal, ; Comment */ +2013-04-22 22:05 UTC+0200 Przemysław Czerpak (druzus/at/poczta.onet.pl) + * bin/check.hb + * bin/commit.hb + ! added executable attribute + + * doc/xhb-diff.txt + ! xBase++ -> Xbase++, Harbor -> Harbour + + * utils/hbmk2/hbmk2.prg + + show project name in error messages + ! applied Viktor fixes: + 2013-04-17 03:45 UTC+0200 Viktor Szakats (harbour syenar.net) + ! fixed to not leave temp .lnk file on disk with -hbdyn[vm] + targets in win/gcc compiler family + ! fixed win/tcc to not use gcc style .lnk files when creating + -hbdyn[vm] targets + ! added workaround for linker stderr messages redirected to stdout. + It's not perfect but for sure much better then previous behavior. + Now recently created problems like broken *nix builds can be well + seen in stderr output. + 2013-04-22 15:38 UTC+0200 Przemysław Czerpak (druzus/at/poczta.onet.pl) * include/hbapi.h * include/hbapigt.h diff --git a/bin/check.hb b/bin/check.hb old mode 100644 new mode 100755 diff --git a/bin/commit.hb b/bin/commit.hb old mode 100644 new mode 100755 diff --git a/doc/xhb-diff.txt b/doc/xhb-diff.txt index e17df79525..e6b6831933 100644 --- a/doc/xhb-diff.txt +++ b/doc/xhb-diff.txt @@ -1,6 +1,6 @@ This text describes most important differences between Harbour and xHarbour -with some references to Clipper and other compatible compilers like xBase++, +with some references to Clipper and other compatible compilers like Xbase++, CLIP, FlagShip. Many thanks to Pritpal and Viktor for updating this text. I hope that it will be updated in the future also by xHarbour developers, @@ -593,9 +593,9 @@ like: and unlike Clipper both compilers generates correct PCODE which shows 10 12 Maybe in the future we add support for Clipper compatible local variable -initialization covered by -kc Harbor compiler switch. +initialization covered by -kc Harbour compiler switch. -xBase++ uses mixed behavior. Just like Clipper it stores variables with +Xbase++ uses mixed behavior. Just like Clipper it stores variables with initialization expressions but then it generates slightly different code initializing variables one by one without line groping like in Clipper. @@ -614,8 +614,8 @@ it may cause VM crash or runtime error, i.e. this code: eval( s ) return -is cleanly compiled by Clipper and xBase++ but it causes RTE in -Clipper and FATAL ERROR LOG in xBase++. +is cleanly compiled by Clipper and Xbase++ but it causes RTE in +Clipper and FATAL ERROR LOG in Xbase++. Harbour and xHarbour correctly report compile time error for it. @@ -984,12 +984,12 @@ can compile and execute this code: ? "a" $ { "qwe", "abc", "zxc", { "a" } } // result .F. return -Warning! XBase++ also support $ operator for arrays but it makes non - exact comparison so ` "a" $ { "abc" } ' gives .T. in XBase++ +Warning! Xbase++ also support $ operator for arrays but it makes non + exact comparison so ` "a" $ { "abc" } ' gives .T. in Xbase++ and .F. in xHarbour or in Harbour when xHarbour compatibility - library is used. Harbour users who need strict XBase++ compatibility + library is used. Harbour users who need strict Xbase++ compatibility should create own code to overload $ operators used for arrays - which will follow exact XBase++ rules. + which will follow exact Xbase++ rules. CLIP also has some code for such extension but it has two bugs. 1-st is a semi bug: it uses non exact comparison but reverts arguments so ` "abc" $ { "a" } ' gives .T. @@ -1095,15 +1095,15 @@ Here is simple code which illustrates it: aeval( a, { |x| qout( x ) } ) return -This problem is also fixed in xBase++ so it's possible to exchange code -using such expressions between Harbour and xBase++. +This problem is also fixed in Xbase++ so it's possible to exchange code +using such expressions between Harbour and Xbase++. In xHarbour the behavior of such expressions in in practice undefined. In most of cases it behaves like Clipper (i.e. it gives the same wrong results in above example) but not always because some not cleanly implemented extensions changed above behavior for chosen operators executed in some context (i.e. modifying -= to += in above example causes that xHarbour generates correct code which give the same results -as Harbour and xBase++). Additionally so far no one has tried to control +as Harbour and Xbase++). Additionally so far no one has tried to control such things in xHarbour compiler so the behavior of different operators and/or context where they behaves differently has been changing few times as side effect of some other modifications. @@ -1126,7 +1126,7 @@ are send to exactly the same object. This example illustrates it: ?? " F()" return o -In Harbour and xBase++ function F() is executed only once for each +In Harbour and Xbase++ function F() is executed only once for each expression but in Clipper and xHarbour once for 'assign', then twice for 'predec' and finaly three times for 'postinc'. In this code function f() returns the same object 'o' on each call so it's not a problem but code @@ -1581,7 +1581,7 @@ without class object) though xHarbour wrongly use class messages as normal messages. In the future we plan to introduce real class objects like in Class(y) and -some other languages (i.e. XBASE++) so it's important for portability to +some other languages (i.e. Xbase++) so it's important for portability to write code which is Class(y) friendly and never use class function directly as constructor, i.e. instead of writing code like: o := mycls( p1, p2, p3 ) @@ -1596,7 +1596,7 @@ be redefined as constructor in user class. Instead :INIT() method should be used as constructor. It's executed automatically when object is created from the :NEW() method. -In Class(y) and xBase++ class function never returns final object. +In Class(y) and Xbase++ class function never returns final object. It returns class object which is completely different and this object understands few messages which allow to manage class, check inheritance scheme, check object definition and access many different information @@ -2075,19 +2075,19 @@ is write access to the same item with complex variable. This part have to be synced by user and automatic synchronization here will strongly reduce scalability. -Harbour also support xBase++ compatible MT API with SYNC and CLASS SYNC +Harbour also support Xbase++ compatible MT API with SYNC and CLASS SYNC methods, SIGNAL and THREAD classes, work area zones and thread functions. -It allows to easy port xbase++ code to Harbour. The main difference -between Harbour and xbase++ is write protection to complex items. +It allows to easy port Xbase++ code to Harbour. The main difference +between Harbour and Xbase++ is write protection to complex items. Harbour gives only read protection so threads can access the same complex variable simultaneously without any restrictions as long as it's not modified (assigned) by some other thread. Assign operations to variable which can be accessed simultaneously by other threads -need explicit synchronization by user code. In xBase++ it should +need explicit synchronization by user code. In Xbase++ it should be synced automatically so users have to use own synchronization only to keep synced his application logic. -For sure xBase++ is more user friendly here. Anyhow such solution +For sure Xbase++ is more user friendly here. Anyhow such solution strongly reduce scalability so the cost of such automatic protection is very high. Additionally in most of cases simultaneous access and assign operations on the same complex variable need additional @@ -2119,10 +2119,10 @@ it in last years. This feature in xHarbour was implemented only in .c code generated by xHarbour compiler (-gc[0-3] output) so it was never working with .hrb (-gh) files or some interpreters like xBaseScript. xHarbour has support for SYNC methods which were designed to replicate -xBase++ functionality but their real behavior is neither xBase++ nor -Harbour compatible. It seems to be close to SYNC CLASS methods in xBase++ +Xbase++ functionality but their real behavior is neither Xbase++ nor +Harbour compatible. It seems to be close to SYNC CLASS methods in Xbase++ and Harbour though it's not exactly the same. There is no support for -real xBase++ SYNC methods and xBase++ MT programming functions and classes. +real Xbase++ SYNC methods and Xbase++ MT programming functions and classes. In summary MT mode in xHarbour looks like a work in progress, started few years ago and never finished. Instead some other core code modifications @@ -2149,10 +2149,10 @@ far from current Harbour functionality and quality. ### THREAD LOCAL WORK AREAS AND CONCURRENT WORK AREA ACCESS ### ===================================================================== -In Harbour and xBase++ work areas are local to the thread. It means +In Harbour and Xbase++ work areas are local to the thread. It means that each thread has its own independent work areas and aliases. Anyhow it's possible to move work area from one thread to other one -using known from xBase++ zero space. In xBase++ each thread can +using known from Xbase++ zero space. In Xbase++ each thread can move his work area to zero space using: DbRelease( [|], [] ) --> lSuccess Then this work area can be attached by other thread using: @@ -2195,7 +2195,7 @@ Setting _SET_WORKAREAS_SHARED to .F. disables global work areas and switches to thread local ones. There is no technical or mathematical reason to keep such strange implementation because it does not give any new functionality to -programmer in comparison to xBase++ and Harbour but allows to easy +programmer in comparison to Xbase++ and Harbour but allows to easy corrupt RDD internals. diff --git a/utils/hbmk2/hbmk2.prg b/utils/hbmk2/hbmk2.prg index 112b18fb05..d9c315cf57 100644 --- a/utils/hbmk2/hbmk2.prg +++ b/utils/hbmk2/hbmk2.prg @@ -677,6 +677,7 @@ STATIC PROCEDURE hbmk_local_entry( ... ) LOCAL lHadTarget LOCAL cParam1L + LOCAL cTargetName /* for temp debug messages */ @@ -775,6 +776,7 @@ STATIC PROCEDURE hbmk_local_entry( ... ) nTarget := 0 nTargetPos := 0 lHadTarget := .F. + cTargetName := "" FOR EACH tmp IN aArgsProc DO CASE @@ -785,12 +787,14 @@ STATIC PROCEDURE hbmk_local_entry( ... ) IF nTarget == nTargetTO_DO AAdd( aArgsTarget, tmp ) nTargetPos := Len( aArgsTarget ) + cTargetName := hb_FNameName( tmp ) ENDIF CASE Lower( Left( tmp, Len( "-target=" ) ) ) == "-target=" ++nTarget IF nTarget == nTargetTO_DO AAdd( aArgsTarget, SubStr( tmp, Len( "-target=" ) + 1 ) ) nTargetPos := Len( aArgsTarget ) + cTargetName := hb_FNameName( tmp ) ENDIF OTHERWISE IF ! lHadTarget .OR. nTarget == nTargetTO_DO @@ -817,7 +821,8 @@ STATIC PROCEDURE hbmk_local_entry( ... ) IF nResult != _EXIT_OK IF lExitStr - OutErr( hb_StrFormat( _SELF_NAME_ + ": " + I_( "Exit code: %1$d: %2$s" ), nResult, ExitCodeStr( nResult ) ) + _OUT_EOL ) + OutErr( hb_StrFormat( _SELF_NAME_ + iif( ! Empty( cTargetName ), "[" + cTargetName + "]", "" ) + ; + ": " + I_( "Exit code: %1$d: %2$s" ), nResult, ExitCodeStr( nResult ) ) + _OUT_EOL ) ENDIF IF lPause OutStd( I_( "Press any key to continue..." ) ) @@ -4354,7 +4359,10 @@ STATIC FUNCTION __hbmk( aArgs, nArgTarget, nLevel, /* @ */ lPause, /* @ */ lExit AAddNotEmpty( hbmk[ _HBMK_aOPTCX ], gcc_opt_lngc_fill( hbmk ) ) AAddNotEmpty( hbmk[ _HBMK_aOPTCPPX ], gcc_opt_lngcpp_fill( hbmk ) ) cBin_Dyn := cBin_CompC - cOpt_Dyn := "-shared -o {OD} {LO} {FD} {IM} {DL} {LS}{SCRIPT_MINGW}" + cOpt_Dyn := "-shared -o {OD} {LO} {FD} {IM} {DL} {LS}" + IF !( hbmk[ _HBMK_cCOMP ] == "tcc" ) + cOpt_Dyn += "{SCRIPT_MINGW}" + ENDIF cBin_Link := cBin_CompC cOpt_Link := "{LO} {LA} {LS} {FL} {IM} {DL}" bBlk_ImpLib := {| cSourceDLL, cTargetLib, cFlags | win_implib_command_gcc( hbmk, hbmk[ _HBMK_cCCPREFIX ] + "dlltool" + hbmk[ _HBMK_cCCSUFFIX ] + hbmk[ _HBMK_cCCEXT ] + " {FI} -d {ID} -l {OL}", cSourceDLL, cTargetLib, cFlags ) } @@ -7105,6 +7113,7 @@ STATIC FUNCTION __hbmk( aArgs, nArgTarget, nLevel, /* @ */ lPause, /* @ */ lExit aOBJLIST := ArrayJoin( l_aOBJ, hbmk[ _HBMK_aOBJUSER ] ) tmp := ArrayToList( aOBJLIST,, nOpt_Esc, nOpt_FNF, cDynObjPrefix ) + cScriptFile := NIL IF "{SCRIPT_MINGW}" $ cOpt_Dyn fhnd := hb_FTempCreateEx( @cScriptFile, NIL, NIL, ".lnk" ) IF fhnd != F_ERROR @@ -7135,8 +7144,7 @@ STATIC FUNCTION __hbmk( aArgs, nArgTarget, nLevel, /* @ */ lPause, /* @ */ lExit "{DB}" => hbmk[ _HBMK_cHB_INSTALL_BIN ] } ) ) /* Handle moving the whole command line to a script, if requested. */ - cScriptFile := NIL - IF "{SCRIPT}" $ cOpt_Dyn + IF Empty( cScriptFile ) .AND. "{SCRIPT}" $ cOpt_Dyn fhnd := hb_FTempCreateEx( @cScriptFile, NIL, NIL, ".lnk" ) IF fhnd != F_ERROR FWrite( fhnd, StrTran( cOpt_Dyn, "{SCRIPT}" ) ) @@ -13171,7 +13179,11 @@ STATIC FUNCTION hbmk_hb_processRunCatch( cCommand, /* @ */ cStdOutErr ) FClose( hOutErr ) - OutStd( cStdOutErr ) + IF nExitCode != 0 + OutErr( cStdOutErr ) + ELSE + OutStd( cStdOutErr ) + ENDIF ELSE nExitCode := -999 ENDIF @@ -16758,7 +16770,7 @@ STATIC PROCEDURE _hbmk_OutErr( hbmk, cText ) RETURN ENDIF - cSelf := iif( hbmk[ _HBMK_lShellMode ], "hbshell", _SELF_NAME_ ) + cSelf := iif( hbmk[ _HBMK_lShellMode ], "hbshell", _SELF_NAME_ + _hbmk_TargetName( hbmk ) ) IF hbmk[ _HBMK_lShowLevel ] nWidth := Len( cSelf ) + 5 @@ -16778,6 +16790,19 @@ STATIC PROCEDURE _hbmk_OutErr( hbmk, cText ) RETURN +STATIC FUNCTION _hbmk_TargetName( hbmk ) + + LOCAL cName := "" + + IF !Empty( hbmk[ _HBMK_nArgTarget ] ) + cName := hb_FNameName( hbmk[ _HBMK_aArgs ][ hbmk[ _HBMK_nArgTarget ] ] ) + IF !Empty( cName ) + cName := "[" + cName + "]" + ENDIF + ENDIF + + RETURN cName + STATIC FUNCTION LicenseString() #pragma __cstream | RETURN %s This program is free software; you can redistribute it and/or modify