{"push_id":2053532597,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"8cd368594f73842b9ae00b62be5ac734b04835ad","before":"7ffd80d183c58abdf14068711a8c83dfc0a06b9c","commits":[{"sha":"8cd368594f73842b9ae00b62be5ac734b04835ad","author":{"name":"Viktor Szakats","email":"0ade794cbe72ca32ca8665d78c58d417de26f58e@users.noreply.github.com"},"message":"2017-10-16 08:19 UTC Viktor Szakats (vszakats users.noreply.github.com)\n  * README.md\n  * config/dos/djgpp.mk\n  * config/dos/watcom.mk\n  * config/dyn.mk\n  * config/global.mk\n  * config/rules.mk\n  * contrib/hbdoc/hbdoc.hbp\n  * contrib/hbformat/utils/hbformat.hbp\n  * contrib/hbrun/hbrun.hbp\n  * package/mpkg_win_ci.sh\n  * src/Makefile\n  * utils/hbi18n/hbi18n.hbp\n  * utils/hbi18n/Makefile\n  * utils/hbtest/hbtest.hbp\n  * utils/hbtest/Makefile\n    * HB_BUILD_DYN=no is no longer a documented or supported build setting.\n      Historically this setting was introduced to avoid glitches and\n      platforms where harbour.dll support was incomplete/broken. By now it's\n      a fairly stable feature which has some useful properties, e.g. the\n      size saving it allows for Harbour tools, the shorter linking speed\n      when linking apps in shared mode (e.g. while doing development), and\n      last but not least it makes it possible to use dynamically loadable\n      modules (via #require) in hbrun, which means that hbrun can be used\n      to run Harbour scripts that use contribs or other libs. Using scripts\n      can dramatically improve iteration speed as there is no need to\n      compile/link at all. In Harbour's own repository, every test/example\n      code and all tools can be run as scripts, even hbmk2.prg itself.\n      (just try it with `hbrun hbmk2.prg`)\n      In the past, creating harbour.dll had the disadvantages of longer\n      build times of Harbour itself, because each C source had to be compiled\n      twice. But, mingw/clang/msvc and darwin targets no longer require it\n      (and it's possibly something to be cleaned up for other platforms/\n      compilers as well - even more so since these days it's advised for all\n      code to be relocatable for ASLR), so the only overhead is to link\n      harbour.dll _once_. With harbour.dll turned off, this same amount of\n      time is spent every time a Harbour app is built in static mode.\n      If you need a self-contained ('portable') version of hbrun.exe while\n      leaving every build settings to the default, simply copy hbmk2.exe\n      to e.g. hbrun-portable.exe (notice that this will lose dynamic\n      capabilities, i.e. loading packages via #require or 'ext.load' prompt\n      command.)\n      Finally, all this doesn't change Harbour's capabilities of creating\n      fully static executables and static remains the default on Windows.\n    * honor HB_BUILD_SHARED build setting to decide whether to build\n      these executables in shared or static mode: hbdoc, hbrun, hbformat,\n      hbi18n, hbtest. It means that static builds can be forced for these\n      executables using this setting. Previously it dependend on the\n      HB_BUILD_DYN setting directly.","distinct":true,"url":"https://api.github.com/repos/vszakats/harbour-core/commits/8cd368594f73842b9ae00b62be5ac734b04835ad"}]}
{"actor":{"display_login":"vszakats"}}