Hi Przemek,
What do you think in smoothing out the difference between
dll and non-dll code in non-GNU builds? (this means to
enable HB_DYNDLL for all compilations, thus making this
build switch unnecessary, and at the same time the whole
build process much quicker. This would also mean that
HB_BUILD_DLL=yes option is costless, so it can be made
a default non-option.)
LD in GCC for Windows has a feature which create export
table automatically for all public functions when non
of them is explicitly marked as exported and such symbol
table is necessary to link application so it's not necessary
because now non exported binaries can be used to create DLL.
BTW few weeks ago I added some missing HB_EXPORT to functions
used in -gc3 output and I intentionally made it only in
header files. Looks that it works for all supported compilers
so we can safely remove HB_EXPORT from .c files.
Thanks for clarifying this.
I'll remove them.
I don't understand the other part of your answer, maybe
my question wasn't very clear. This topic seems to only
affect BCC / MSVC, GCC is much cleaner probably.
So, currently BCC/MSVC does two passes, one for static
libs and executables using these static libs, plus
there is an additional pass, when certain object are
recompiled with functions marked as exported to build
harbour.dll. This second pass uses -DHB_DYNLIB and it
only kicks in if 'HB_BUILD_DLL=yes' (default is 'no').
'HB_BUILD_DLL=yes' makes whole process take almost
twice as much time (and disk space). Also, building
hbrun-dll won't work this way unless we create even more
complications.
So, it's time that we make HB_DYNLIB the default, which
instantly makes the second pass unnecessary, it also
fixes hbrun-dll build problem. This way building .dlls
has no significant drawbacks, and could be enabled
for default builds, making also HB_BUILD_DLL option
unnecessary (and closing the gap between GNU and
non-GNU makes somewhat).
The only perceivable drawback is some executable size
increase for BCC/MSVC (max 100K), plus the fact that
all Harbour executables will export certain (used)
Harbour functions.
I was wondering if you have any concerns going to this
direction?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
