Hi Przemek,
and one more: as hbrun seems to be the more
widespread and even xhb compatible exectuable
name, and it might also be referred by scripts,
I'd rather recommend to rename hbdot to hbrun,
and drop current hbrun.
hbdot cannot cleanly execute .hrb files yet but
of course it can be quite easy added. In POSIX
we can even create hbdot link to hbrun for backward
compatibility and to force interactive mode when
run without parameters: it's enough to check hb_argv(0).
Please check me, I've already added this to hbdot.
[ One such .exe is 1.5-2MB large depending on
the platform/compiler. ]
The size is important only in static builds.
In shared builds (make_rpm*.sh, make_tgz.sh) both binaries
are linked with harbour shared library (.dll, .so, .dyn, .sa, ...)
and the size is much smaller ~150KB and most of this is symbol
table with all hbextern definitions which also can be eliminated.
We should only create new hbextern library and add it to harbour
shared library. Now in shared library all .prg functions
are accessible even without including hbextern.ch because .prg
code automatically registers all used symbols. It does not happen
for .c code so Harbour functions written in C which are not accessed
directly by some .prg code are not registered in HVM by harbour.dll
startup code. Such hbextern library can resolve this problem and
I would like to add it even only for this.
hbrun without #include "hbextern.ch" linked but with harbour.so
having all hbextern symbols has only 5KB.
For me it's not a problem if we will have two tools with such
small size. Anyhow before we remove one of them IMHO we should add
hbextern library and try to add support for shared builds for
non GCC conpuilers.
The size is a problem for all non-Unix builds currently, so it
would be good to deal with it. Even if a .dll based build is
technically possible in Windows, I think one of the strengths of
hbdot/hbrun, that they are self-contained, easy to run just by
having the .exe. Also the functionality of hbrun/hbdot is so
much overlapped that it might be better to have them as one
utility anyway. At least IMO.
Regardless of the merge, all you write can just make everything
even better.
If there are no objections, I'll replace current hbrun code
with hbdot code, and remove hbdot.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
