> > > Second issue of the unified and self-contained Windows release > > package, which is able to create x86, x64, WinCE/ARM executables > > (both shared and static) out of the box without the need of any > > external tools or settings. This time also in the form of installer, > > with (de)selectable options. > > Downloads: > > http://www.syenar.hu/harbour/harbour-11-win-20090331.7z (size: 146MB) > > http://www.syenar.hu/harbour/harbour-11-win-20090331.exe (size: 148MB) > > To use: > > 1) unpack/install to any directory (C:\harbour-11) > > 2) go to bin dir (optional if you specify path for hbmk2) > > 3) For x86 executable type: 'hbmk2 ../tests/hello.prg' > > 4) For x64 executable type: 'hbmk2 ../tests/hello.prg -comp=mingw64' > > 5) For WinCE/ARM executable type: 'hbmk2 ../tests/hello.prg > -comp=mingwce' > > Very nice. Looks that using Harbour in Windows begins to be as simple > as in *nixes ;-). Thank you very much.
:) You're welcome. > I have one request here. Please add to hbmk2 support for detecting > CLIPPER and RTLINK as base names and switch to -hbcmp/-hblnk mode > automatically plus add support for rtlink @file.lnk in such link mode. > It should greatly help existing Clipper users to make some tests > with Harbour. F.e. it will be enough to make: > copy hbmk2.exe clipper.exe > copy hbmk2.exe rtlink.exe > and make tests using existing Clipper build scripts, f.e. with rmake.exe > Of course if user does not use any 3-rd party libraries. > >From .lnk file important is only list of files after FILE directive > but we can add also support for LIB parsing and some basic translation > for used lib names. AFAIR other directives can be ignored. Such parser > can be implemented as separated single function and probably can be used > also for BLINKER .lnk files. I've added clipper/rtlink recognition, but I miss the .lnk parser code, and to be frank I don't really know its exact details (used to use "FI hello1, hello2"), so if you happen to have some/any piece of such parser code I'll can tackle it to hbmk2. > The whole distro is rather huge though it should not be big problem > for normal usage. But if we have support for above CLIPPER/RTLINK Yes, it's not small. For me it's a problem only because it's a very heavy job to update them, takes hours to be assembled / uploaded even without counting the build-times themselves. Anyhow, it's well suited for final releases, because we don't have that many of those anyway, and target builds have to be generated anyway. So it's much better than current dozen of harbour-1.1-win-*.zip files. > emulation then we should think also about creating some minimal > Harbour distribution with some small C compiler (f.e. POCC) for > x...@32 only as startup and for Clipper users who want to make some > tests with Harbour. I did a quick test with a 'lite' package and the .7z file is 17MB (same is the install .exe), installed size 117MB. This contains MinGW libs and also MinGW x86 embedded version. POCC has a few problems, so I'm not really interested in investing more time in it, it's slower, has bugs, bad 3rd party support (not QT support f.e.), and also needs special environment setup to make its compiler work, MinGW looks superior choice from all aspects besides distro size. BTW, for comparison a pure POCC build with POCC included has a 12MB installer and installed size is 77MB. 5MB dl and 40MB installed overhead is well worth being on the standard path with a heavy duty, standard tool like MinGW/GCC IMO. So ideally we should distribute these Windows files on sf.net: - harbour-1.1.0-win.exe - harbour-1.1.0-win.7z - harbour-1.1.0-win-mingw.exe (aka 'lite' or 'minimal') - harbour-1.1.0-win-mingw.7z (aka 'lite' or 'minimal') - harbour-1.1.0-src.zip How to name it? mingw / minimal / light / lite? Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
