Hi Przemek,
Hi Viktor,
HB_EXPORT is also a perfect name. As for making it the
We already use HB_EXPORT for exported function attributes
though it's wtill possible to use the same name.
In hbdefs.h we will have to make sth like:
#ifdef HB_EXPORT
#undef HB_EXPORT
[define new HB_EXPORT]
#endif
Ops, that's probably the reason I didn't choose it
back then. Well, anyway, it'd be better to use
something different for clarity, pls find a good
name beginning with HB_ and containing EXPORT, I'm
not really familiar with the exact context to give
a proper name here.
default, it would actually be great, as - but I may be
wrong - it would make the separate compile process for
.dll creation unnecessary in non-GNU builds. I may
also enable .dll creation for BCC/MSVC in GNU-builds.
Yes, it will not be necessary to make separate compilation for
shared library on some platforms if shared library does not need
relocatable code.
Great!
Question, what disadvantage would it have, why wasn't it
turned on so far?
There are two differences:
1. a little bit bigger binaries because the size of exported
symbol table will be bigger.
This is IMO not a problem at all.
2. It will be possible to access exported symbols from other DLLs
(this is what we need to load PCODE DLLs though to be precise
it's not strictly necessary and we can add workaround for it,
in some cases it may be even interesting so probably I'll
implement such functionality)
Can't really see the consequences, but it doesn't
look like a fatal problem to me.
Okay. Pls note that we now have the version number
in the .dll names. The whole .dll generation is still
a mess, so it's pretty hard to build on it, but other
than this I see no problem with your change at all.
The harbour*.dll is not used with static binaries at all and
as you can see in the code I send there is workaround for MSVC and
BCC names though I do not know if the extensions were not recently
changed.
Sorry, but I cannot really oversee the whole .dll matter,
it's pbly a personal thing that I find them very rarely
useful, but problems with them are plenty, therefore so far
I've been trying to avoid them as much as possible.
IOW, feel free to do as you think best :)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
