>> - If the binary release is up to me, I'll >> leave out DJGPP build, since I don't possess a >> dev environment for it anymore. watcom/dos build >> can be included, but I'm not sure if it's >> worth it. > > I can create DJGPP and OpenWatcom Harbour binaries.
The watcom ones are no problem, since I can use the win tools to create them, I just can't see a point in including them in windows unified release. Would be good to hear opinions from users. Or any argument for including them. It's a lot of extra time. For DJGPP, it's good and thank you, but if we go with the unified build, we need some careful syncing to put everything in place. Maybe better would be to distribute them separately in non-unified package. > BTW Creating Harbour shared libraries in OW Dos builds does not > work due to some insufficient dependencies in DLL startup code so > OW tries to link both startup code (also for standalone binaries) > into harbour.dll. At least when I use OW in Linux. Does it work > for you on other platforms?. If not then I suggest to temporary > disable creating harbour.dll in dos/watcom.mk by simple modification > like: > > ifeq ($(HB_BUILD_DLL),yes) > DY_RULE = $(create_dynlib) > endef I don't think watcom dos .dlls ever worked, for sure they didn't work for me ever. I also recall placing TOFIX/TODO notes regarding it in ChangeLog, but it's possible I don't remember correctly. As for disabling them, 'yes' is the default for HB_BUILD_DLL. Again possible I'm missing something, pls do it as per your best judgment. > Maybe we should also use the same method in DJGPP. > If someone adds support for -shared binaries in new DJGPP > versions then it will be enough to rebuild Harbour setting > HB_BUILD_DLL=yes. Such solution is also more flexible for > testing but if you prefer to fully comment DY_RULE then of > course it's also OK for me. I trust your judgment, you know these DOS platforms much better than I do, plus I don't have them handy, so just do it you feel best. >> - Should we include watcom/os2 and watcom/linux >> in final win binary release? IMO the only >> reason is for technological showcase, but >> I doubt any win users would actually use these. >> Leaving it out saves build time, package size >> and upload/download time. > > Maybe we should create separate MS-Windows package with only > OW binaries which will allow to create Harbour applications > for all platforms? Possibly. IMO the easiest, simplest and already implemented method is to simply create non-unified packages for them (HB_BUILD_PKG=yes). OW unified package needs extra work. Here one problem is that it'd need a multi-binary layout which is already supported by hbmk2, but since it's overall new thing, it needs some time/testing. In this case, even embedded OW C compiler could be added. Format should be simple .zip probably. For me it looks like too much work, but maybe someone can do it. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
