>> Before going further can you help define in >> normal words what is the description / distinction >> between -hbdyn and -hbdynvm modes? > > -hbdyn creates DLL which is not linked with HVM. > -hbdynvm creates DLL which is linked with HVM and > other Harbour core libraries. > >> When do we use which mode? > > When we need or not HVM to be linked with final dynamic > library so it depends on the code I'm linking. > I can use -hbdyn to create DLL which does not have any > references to Harbour core code. > I can use -hbdyn and -lhbmaindllp to create DLL containing > compiled .PRG modules (PCODE DLL) which can be dynamically > loaded by static or dynamic Harbour application. > I can use -hbdyn and -static to create self contain DLL > which uses it's own private copy of HVM and Harbour RTL > library which can be linked statically or loaded dynamically > with/from any other applications, this application can use > it's own HVM copy which will not interact with the one included > in DLL in any way. > I can use -hbdynvm and -shared to create PCODE DLL which can > be linked statically or loaded dynamically by shared linked > Harbour application and HVM code and structures are shared > in such case. > There are also many other situations when user may need -hbdyn > or -hbdynvm. > >> [ we now have .prg .dlls, "normal" .dlls, "VM" >> .dlls, but I'm starting to get confused, which >> means it's difficult to organize the internals. >> F.e. now I can introduce a new sub-switch inside >> -hbdyn mode for 'vm', or I could cleanup the modes >> into a flat list. ] > > See above. > Please also remember that dynamic shared libraries using HVM > are initialized just like normal EXE files and when they contain > their own HVM switches like -gt* should be enabled just for executable > binaries. If they share HVM then you can also enable them and they will > be ignored so you do not have to implement any special case for such > situation.
Thank you, it more clear now. I'm quite busy now with other thing, but I'll make the hbmk2 changes ASAP. >> Enabling specific features based on the mode is >> less of a problem. >> >> Bonus: Do you have any hint how to use .def files >> with watcom compiler? Spent 1 hour on it to no avail, >> maybe it's too obvious or it was too late. > > See my second message. WLINK seems to not accept .DEF files > directly and uses a little bit different syntax. Only LINK > can accept them and probably internally translates them to > WLINK format. We can add translation from .DEF files to this > format or we can simply include .DEF files directly using "@" > command in WLINK .lnk file and user will have to use OpenWatcom > compatible format for them. Okay, I forgot for a moment watcom has a LINK command also. So we have four options: 1. Let users mess with creating a watcom .def file 2. Let hbmk2 do the conversion to temp file and pass that to WLINK 3. To use LINK instead of WLINK for win/watcom targets. 4. To use LINK instead of WLINK for win/watcom targets when .def file specified. 2. seems to be the best on the long run. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
