Harbour nightly builds

[Sergy]

Hello friends.

I'm not too qualified developer to build Harbour and use nightly builds from here: http://sourceforge.net/projects/harbour-project/files/ (The link "Downloads" from top of this forum).

The latest build is 2016-01-02, but changelog.txt has last record about one moth ago:

/*

 * $Id: cc052b94d695e20623b4f41ff1a4e6f4a7aabbf3 $

 */

/* Read doc/howtorep.txt and use this format for entry headers:

   YYYY-MM-DD HH:MM UTC[-|+]hhmm Your Full Name (your_email address)

   2013-12-31 13:59 UTC+0100 Foo Bar (foo.bar foobar.org)

   See copyright/license at the end of the file.

   Encoding: UTF-8 (No BOM)  Notation (in 5th position):

     * Change, ! Fix, % Optimization, + Addition, - Removal, ; Comment

 */

2015-12-05 10:58 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)

  + tests/getblock.prg

    + added test code for GET SetGet block for aliased macro variables

2015-12-05 10:05 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)

  * src/rtl/gtos2/gtos2.c

    ! fixed GCC builds - many thanks to David Macias
...

What it can be ?

Where I can download the really latest build ?

Thank you.

WBR,

Sergy

[Francesco Perillo]

I will start a new build later today.

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vszakats]

You can pick a binary from here:

    https://github.com/vszakats/harbour-core/releases/tag/v3.4.0dev

It works rather reliably. It's rebuilt after each commit. Now it also 

includes full curl/openssl stack for static linking. Uses mingw 5.3.0.

-Viktor

[Sergy]

Thank you, Viktor.

But now I am very interested in this commit:

2016-01-03 09:24 UTC-0800 Pritpal Bedi (bedipritpal/at/hotmail.com)

  * contrib/gtwvg/wvgcore.c 

  * contrib/gtwvg/wvgcuig.c

    ! Fixed Wvt_DrawImage() and Wvg_Image() where images were not 

   being rendered correctly if the height of image is greater than

   width of the image. The behavior is only affected when <bDoNotScale>

   is set to be TRUE. Thanks Sergy for reporting and providing 

   code to debug.

As I can understand - your fork doesn't have it :(

And second - when I run this *.7z.exe on WinXP SP3 - I have the message "Method not supported"... 

Sorry for such stupid questions... Where I can get a full detailed info about build HB from sources to ready-to-use execuatbles ?

I read this: https://github.com/harbour/core/ - Welcome etc... How to build...

For all platforms you'll need:

Supported ANSI C compiler

GNU Make (3.81 recommended, minimum 3.79 required, see also platform details)

Harbour sources (2.0.0 or upper)

on Windows hosts (possible cross-build targets: Windows CE, MS-DOS, OS/2, Linux)

Platform specific prerequisites:

Windows XP or upper system is recommended to build Harbour.

Make sure to have your C compiler of choice properly installed in PATH. Refer to your C compiler installation and setup instructions for details. It's recommended to make sure no tools in your PATH belonging to other C compilers are interfering with your setup. It's also highly discouraged to keep multiple copies of the same compiler, or different versions of the same compiler in PATH at the same time. For the list of supported compilers, look up Supported Platforms and C Compilers.

GNU Make 3.81 or upper is required. A copy of this tool is included in all Harbour packages, so you don't have to do anything. If you want to get it separately, you can find it here Unpack it to your PATH or Harbour source root directory, and run it as mingw32-make.

To build:

> win-make [install]

To test it, type:

> cd tests

> ..\bin\hbmk2 hello.prg

> hello

You should see Hello, world! on screen.

How I can "make sure you have C compiler" ? I have "old" nightly build and it works fine: compiles my sources very well and fast.

"GNU Make is required" - it's included in all Harbour packages (I can't see it in source) "or you can download it from here" - there is a lot of folders with mingw-make-cvs-etc-...

I'm don't understand - what should to do. If I download some file - where I must place it ?

When I run win-make.exe I see:

D:\core-master>win-make.exe

! Building Harbour 3.2.0dev from source - http://harbour-project.org

! MAKE: D:/core-master/win-make 4.1 sh.exe

! HB_HOST_PLAT: win (x86)  HB_SHELL: nt

config/global.mk:1271: *** ! HB_COMPILER not set, could not autodetect.  Stop.

Where I should set HB_COMPILER ?

In system SET ?

In the system path ?

In some of makefile ? Which one ?

I don't understand, sorry... 

Hope there is a full guide.

Thank you very much for your support.

Sergy

вторник, 5 января 2016 г., 18:31:48 UTC+3 пользователь vszakats написал:

[Massimo Belgrano]

i receive error during install

Is mingw 5.3 compatible with qt?

--

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[vszakats]

On Tuesday, January 5, 2016 at 5:03:13 PM UTC+1, Sergy wrote:

Thank you, Viktor.

But now I am very interested in this commit:

2016-01-03 09:24 UTC-0800 Pritpal Bedi (bedipritpal/at/hotmail.com)

  * contrib/gtwvg/wvgcore.c 

  * contrib/gtwvg/wvgcuig.c

    ! Fixed Wvt_DrawImage() and Wvg_Image() where images were not 

   being rendered correctly if the height of image is greater than

   width of the image. The behavior is only affected when <bDoNotScale>

   is set to be TRUE. Thanks Sergy for reporting and providing 

   code to debug.

As I can understand - your fork doesn't have it :(

How did you arrive to this conclusion?

And second - when I run this *.7z.exe on WinXP SP3 - I have the message "Method not supported"... 

You'll need to unpack it with 7-zip then.

XP support is fading from most tools, apparently even from the sfx 

module. Haven't done testing XP in a very long time and I'm targeting

Win7 as a minimum requirement at least for the dev env. End-user 

apps should still run fine on XP SP3 though.

Sorry for such stupid questions... Where I can get a full detailed info about build HB from sources to ready-to-use execuatbles ?

After unpacking, you can read BUILD.txt, RELNOTES.txt, README.md.

You can also inspect the full build script and all the related changes, 

if interested in such details.

-Viktor

[vszakats]

Too bad, thanks for the information. I'll remove the sfx for now.

Anyhow the file is named .7z because it's also a valid .7z file.

As for QT, I'm not following what's happening on that front. I'm 

using the dual-target mingw builds, which are posix, sjlj. The 

same mingw is used for automatic build purposes.

If that's not good for some purposes, another build flavour can 

also be used, but of course, it has to be built from source.

-Viktor

[vszakats]

Hopefully fixed in the next build:

   https://github.com/vszakats/harbour-core/commit/83e981dd71e7670783333992cde9d960dae28db5

It will be finished in about 25 minutes (if no error):

   https://ci.appveyor.com/project/vsz/harbour-core/build/3.4.865

-Viktor

On Tuesday, January 5, 2016 at 5:20:46 PM UTC+1, Massimo Belgrano wrote:

[Francesco Perillo]

Info on building www.mozzarellaincarrozza.it/harbour/compiling-harbour-for-qt-from-git/#comment-110

--

[Pete]

Hi Viktor

On Tuesday, January 5, 2016 at 6:28:06 PM UTC+2, vszakats wrote:

 

using the dual-target mingw builds, which are posix, sjlj. The 

I have two questions regarding your distro about which it's significant to have your reply/clarifications.

a. As far as I can see, you have ceased "support" of legacy levels 4 & 5.
In case I would want/need  to re-enable them, is it enough to define them in hbsetup.ch?
or should I make and other hacks (and what/where)?

b. I do use win32 threading GCC, but since you state that you're using posix ,
I wonder if  there is any possibility to have any problems when building your distro with win32?

---
Pete

[vszakats]

On Tuesday, January 5, 2016 at 7:05:28 PM UTC+1, Pete wrote:

Hi Viktor

On Tuesday, January 5, 2016 at 6:28:06 PM UTC+2, vszakats wrote:

 

using the dual-target mingw builds, which are posix, sjlj. The 

I have two questions regarding your distro about which it's significant to have your reply/clarifications.

a. As far as I can see, you have ceased "support" of legacy levels 4 & 5. 

In case I would want/need  to re-enable them, is it enough to define them in hbsetup.ch?
or should I make and other hacks (and what/where)?

They can be enabled via HB_USER_* custom options, which is somewhat 

cleaner than patching `hbsetup.ch`. Though I strongly suggest to make those 

few minor updates in your own code which would allow you to _not_ need 

these legacy components. I haven't done it yet, but in the future I plan to 

remove these code parts, as this would the ultimate goal of obsoleting them.

Adapting your own code for these changes should be rather simple, and 

it's also quite well documented. There is also no functionality loss, just 

some reshuffling.

In fact, had 3.2 receive a stable release, level 4 should have been disabled 

in mainline years ago. We're talking about stuff obsoleted as early as _6_ 

years ago (2010). This is plenty of time to adapt to these minor changes.

It's also an option to take all the compatibility cruft (protected by `HB_LEGACY_LEVELn` 

guards) and copy them to app code and maintain them locally forever.

b. I do use win32 threading GCC, but since you state that you're using posix ,
I wonder if  there is any possibility to have any problems when building your distro with win32?

For Harbour this GCC/mingw distro option doesn't seem to matter at all, 

at least I had well working MT apps on Windows both with the `win32` 

and the `posix` builds.

Some dependencies I don't use, might require one or the other, but that's 

all I know about it.

-Viktor

[Pete]

Viktor,

thanks for your answer. i think it helps to clear up things for a potential transition to hb34.

 I haven't done it yet, but in the future I plan to 

remove these code parts, as this would the ultimate goal of obsoleting them.

this sounds like much a drastic move!
not sure if it would make all hb34 people happy though,
but it's your own matter/decision anyway.

 

Adapting your own code for these changes should be rather simple, and 

it's also quite well documented. There is also no functionality loss, just 

some reshuffling.

well, your suggestions about adapting / reshuffling code, are undoubtedly welcome!
(if only they weren't in such a strong conflict with the well-known --and shameful too-- programmer's innate 'laziness' .. ;-) )
however, leaving joking aside, we must admit that for new-written code this is the correct way to follow.

 

In fact, had 3.2 receive a stable release,

I hope we would be happy to see it happens during this year or some day later.. ;->

 

b. I do use win32 threading GCC, but since you state that you're using posix ,

I wonder if  there is any possibility to have any problems when building your distro with win32?

For Harbour this GCC/mingw distro option doesn't seem to matter at all, 

at least I had well working MT apps on Windows both with the `win32` 

and the `posix` builds.

That's good to know.
thanks again!

---
Pete

[vszakats]

On Tuesday, January 5, 2016 at 9:16:58 PM UTC+1, Pete wrote:

Viktor,

thanks for your answer. i think it helps to clear up things for a potential transition to hb34.

 I haven't done it yet, but in the future I plan to 

remove these code parts, as this would the ultimate goal of obsoleting them.

this sounds like much a drastic move!
not sure if it would make all hb34 people happy though,
but it's your own matter/decision anyway.

For most people it means renaming some obscure function calls.

(usually the OEM2ANSI ones)

Even if those calls are made from closed-sourced components 

only available in binary form, a simple wrapper can be created 

or copying the hacks from Harbour to own code as I wrote above.

Also not a huge issue.

So it's not an MS-DOS to Windows, or Python 2.x to 3.x level 

of issue. It's minor. Probably a Win7 to Win8 transition is 

riddled with much more problems.

Obsoleting stuff is normal operation in software development,

unless you want end up in a mess, or unless you can see the 

future an advance and also never make a mistake during 

development.

Thus for me, it's rather incomprehensible what is the apparent 

large fear around this. Can someone enlighten me?

 

Adapting your own code for these changes should be rather simple, and 

it's also quite well documented. There is also no functionality loss, just 

some reshuffling.

well, your suggestions about adapting / reshuffling code, are undoubtedly welcome!
(if only they weren't in such a strong conflict with the well-known --and shameful too-- programmer's innate 'laziness' .. ;-) )
however, leaving joking aside, we must admit that for new-written code this is the correct way to follow.

I have no prepared suggestions at this time, but each 

time a HB_LEGACY_LEVEL exception is committed, 

short instructions and explanation is posted next 

to it in ChangeLog.txt. So if you have a missing symbol 

at link-time, just do a text search for it, or just do a text 

search for HB_LEGACY_LEVEL to browse them all and 

see if you're affected by any one of them.

When there is Harbour sources needing related 

updates, it's also committed in the same or one of 

the subsequent commits as a live example of what 

needs to be done.

On forums like this one, there is usually useful 

suggestion when a related, specific question comes up.

I hope we would be happy to see it happens during this year or some day later.. ;->

Sure, but it still requires time and labour, with not 

much to gain in return, so I'm not surprised nobody 

took the "challenge" yet.

Actually the labour and time was already spent 

on the technical parts in the automated 3.4 releases, 

but who will be the lucky one putting the "stable" 

stamp on a specific revision? And write a detailed 

doc summarising the changes? Then support it (?).

What is really the expectation of a stable release?

And if it's so important, why wasn't there anybody to 

do it yet?

 

b. I do use win32 threading GCC, but since you state that you're using posix ,

I wonder if  there is any possibility to have any problems when building your distro with win32?

For Harbour this GCC/mingw distro option doesn't seem to matter at all, 

at least I had well working MT apps on Windows both with the `win32` 

and the `posix` builds.

That's good to know.
thanks again!

No probs!

-Viktor

[Sergy]

Hi Viktor

How did you arrive to this conclusion?

As I can see in changelog.txt:

/* YYYY-MM-DD HH:MM UTC[-|+]hhmm Your Name (your_email address)

   Encoding: UTF-8 (No BOM)  Notation (in 5th position):

     * Change, ! Fix, % Optimization, + Addition, - Removal, ; Comment

   Get accurate and dynamic log using command:

     git log --pretty=medium --no-merges --date=iso --abbrev-commit HEAD~50..HEAD

   See license at the end of file. */

2016-01-03 17:19 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * package/mpkg_win.sh

    * move licenses to root of the package

    * cleanup filetypes that are packed into the bin dir

      (now only executables and no batches)

2016-01-03 17:06 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * package/getmingw.hb

  * package/mpkg_win.sh

    % burn-in version at packaging time instead of rolling it there

      manually

2016-01-03 17:02 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * package/getmingw.hb

    % minor cleanup

2016-01-03 16:59 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win.sh

    + bundle 64-bit 7za.exe for 64-bit hosted packaging

    + bundle curl.exe

  * package/getmingw.hb

    % drop JS download hack. With bundled curl.exe, this is no longer necessary

2016-01-03 16:43 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

    * add reduced list of contribs in case lto build wouldn't fit in

      40 minutes

  * package/mpkg_win.sh

    ! fix non-master builds to not remove master tag

2016-01-03 15:01 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * package/mpkg_win.sh

    * replace Git for Windows specific find hack with a cleaner solution

    ! fix a missing quoting

2016-01-03 14:38 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win.sh

    + be 64-bit hosted in lto branch

2016-01-03 14:30 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

    ! move back mpkg_win.sh to its former place

2016-01-03 13:26 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win.sh

    * fix a mistake

    * remove one hack once again

2016-01-03 12:45 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win.sh

    * restore two hacks

    * protect curl with local set

2016-01-03 12:13 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win.sh

    * move problematic curl call to shell script

    * remove hack required by above curl call

    * move mpkg_win.sh call to 'before_deploy' stage

    * try removing the 'find' hack as well

2016-01-03 12:03 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win_dl.sh

    * tweak displaying '*_VER' variables

    % submit to VirusTotal only master builds

      (max size is 128MB, LTO builds are larger than that)

    + enable LTO mode for the 'lto' branch

2016-01-03 04:21 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

    * alignment

2016-01-03 03:59 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * appveyor.yml

  * package/mpkg_win_dl.sh

  * package/mpkg_win.sh

    * eliminate a variable from appveyor.yml

    * move curl/openssl package hashes next to the version numbers

      in appveyor.yml

2016-01-03 02:25 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * contrib/hbzebra/qrcode.c

    * url update

2016-01-03 02:12 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * ChangeLog.txt

  * README.md

    * https urls

2016-01-02 21:59 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)

  * package/getmingw.hb

  * package/mpkg_win_dl.sh

    * update to mingw/gcc 5.3.0

    ; URLs (that point to sfnet mirrors) may need some time get live

  * win-make.exe

    * updated from:

      https://www.mirrorservice.org/sites/dl.sourceforge.net/pub/sourceforge/m/mi/mingw-w64/Toolchains%20targetting%20Win32/Personal

      includes fix for this problem:

         https://stackoverflow.com/a/33378517/1732433

There is no commits in 2016 from Pritpal.

After unpacking, you can read BUILD.txt, RELNOTES.txt, README.md.

You can also inspect the full build script and all the related changes, 

if interested in such details.

Thank you. I will read.

Sergy

[vszakats]

You picked an old copy of ChangeLog.txt, which missed just that

commit (and everything else since). Notice that merged entries 

may not always be precisely sorted, which could be worse with 

Pritpal's commits, because they come from timezone -08:00. 

Anyhow I suggest to use a text search on the latest state (or the 

one you find inside the latest binary) of ChangeLog.txt.

Alternatively you may look for a list of commits here:

    https://github.com/vszakats/harbour-core/commits/master

Or do the same using a Git command-line client as suggested 

at the top of ChangeLog.txt:

    git log --pretty=medium --no-merges --date=iso --abbrev-commit HEAD~50..HEAD

(similar feature is available in all Git GUI clients as well)

-Viktor

[Sergy]

Thank you very much, Viktor - for your help to novices like me and all Harbour community.

I was lost in the forest of code and files.

Now I will read and sort out - which differences between "common" 3.2 and "your" 3.4 more precisely.

WBR, Sergy.

среда, 6 января 2016 г., 13:30:05 UTC+3 пользователь vszakats написал:

[Sergy]

Hi Viktor

I downloaded, unpacked all from exe from harbour-daily-win.7z.exe

I downloaded new mingw and installed it

But when I compile my app I receive:

hbmk2: Error: Referenced, missing, but unrecognized Harbour function(s):

       HB_LANG_RU866()

Text search "LANG_RU866" all-deep-in-folder \hb34 gives nothing. Can you give me the direction to solve this ?

Thank you.

[Francesco Perillo]

Just to say that a new build of official harbour is available on SourceForge.

[vszakats]

Sergy,

Yes, it's described in this ChangeLog entry:

    2012-07-24 15:04 UTC+0200 Viktor Szakats

Please read the whole text, but the end result is something like this:

   hb_langSelect( "ru" )  // call this after you've set the HVM CP to "RU866"

And to replace

   REQUEST HB_LANG_RU866

with

   REQUEST HB_LANG_RU

-Viktor

[Sergy]

Just downloaded from link in head of this board: http://sourceforge.net/projects/harbour-project/files/

The harbour-nightly-win.exe file file from "binaries-windows\nightly" folder has size 36 651 873 bytes.

changelog.txt last updated 2015-12-05.

Pritpal's commit not included - as I can see by my test.

Can you point me - where is "new build" ?

Thank you.

четверг, 7 января 2016 г., 0:07:23 UTC+3 пользователь fperillo написал:

[Sergy]

Thank you, Viktor very much.

It works.

Compilation and linking is much faster than "standard" mingw compiler.

четверг, 7 января 2016 г., 0:11:58 UTC+3 пользователь vszakats написал:

[Massimo Belgrano]

Afaik qt choice is posix dwarf 

https://wiki.qt.io/MinGW
also upcoming qt 5.6 https://wiki.qt.io/Qt-5.6.0-tools-and-versions

Dowloaad last hb34 installed and get mingw.53 with  hbrun getmingw.hb`

SET HB_QT_MAJOR_VER=5

SET QTHOME=c:\DVL\Qt\Qt5.5.0\5.5\mingw492_32

SET QTBIN=%QTHOME%\bin

SET HB_WITH_QT=%QTHOME%\include

SET HB_QTPATH=%QTBIN%

SET HRBBIN=c:\hb34\bin

SET QTCONTRIBS_REBUILD=Yes

SET QTPLAT=%QTHOME%\plugins\platforms

SET PATH=%QTPLAT%;%QTHOME%;%QTBIN%;%HRBBIN%;%PATH%

cd \hb34\addons

hbmk2 qtcontribs.hbp -rebuildall

And receive this error

100or F0029  Can't open #include file 'hbqtgui.ch'

hbqtwidgets\misc.prg(56) Error F0029  Can't open #include file 'hbqtgui.ch'

hbqtwidgets\getsys.prg(70) Error F0029  Can't open #include file 'hbqtgui.ch'

hbqtwidgets\slidinglist.prg(69) Error F0029  Can't open #include file 'hbqtgui.ch'

hbmk2 [hbqtwidgets]: Error: Running Harbour compiler job #1. 1

2016-01-05 17:28 GMT+01:00 vszakats <vsza...@gmail.com>:

Too bad, thanks for the information. I'll remove the sfx for now.

Anyhow the file is named .7z because it's also a valid .7z file.

As for QT, I'm not following what's happening on that front. I'm 

using the dual-target mingw builds, which are posix, sjlj. The 

same mingw is used for automatic build purposes.

If that's not good for some purposes, another build flavour can 

also be used, but of course, it has to be built from source.