On Wed, 04 Mar 2009, Szak�ts Viktor wrote:
Hi,
> It would be nice to hear some comments on my fixes,
> I'm not sure what silence means :) But after like 30-40 fixes
> with no positive (or any) feedback it's really difficult to know
> where we stand. I hope we're advancing.
I'm trying but so far I cannot use hbmk2 even in basic
real life tests as hb* script replacement so I do not know
what to comment in in commits. I do not know what it the
work in progress and what is the final version. hbmk2 has
a lot of extenssions I do not know. I believe you that they
give very powerful functionality but 1-st I have to be able
to use hbmk2. In next steps I will have some wish lists.
F.e. I think that with small cost we can add support for
two modes: CLIPPER and RTLINK so new user can simply copy
hbmk2.exe as clipper.exe and rtlink.exe and then set PATH
to Harbour installation make some tests with his existing
Clipper projects without touching even single line in his
build scripts. But this are features which we can add later.
> > I do not know the details of hbmk2 and what how you want to
> > implement it internally. I do not want to force any internal
> > solution for you. Just simply I do not have enough time and
> > possibilities to make tests with different windows compilers
> > and it's the reason I haven't committed my .prg replacement
> > to hb* scripts to SVN.
> After 3-4 weeks of 24/7 dedication I'm running out of free
> time myself, too.
> I'd like to close existing features.
welcome in the team :-)
Maybe my ChangeLog descriptions are often short end enigmatic
but believe me that the whole weekend I was thinking how the resolve
some very serious problems with static variables in core compiler code
without rewriting a lot of code.
> > hb* scripts works only with GCC based compilers so it was quite
> > easy job to have hbcc working. I understand to things are much
> > more complicated when other compilers are also supported and you
> > may need to make it in different way. How is your choice.
> Yes, exactly. That's why I told in the beginning that hbmk2
> can never be a 100% copy of hbmk, the scope is wider, problems
> are different. We should cover what's important, and let those
> which are really problematic or against the concept. One of
> these is passing down C options through hbmk command line
> to the C compiler f.e..
OK. But if it will not cover existing hb* scripts functionality then
we will have no choice then they will have to stay in SVN as alternative
version.
> I'd try getting closer (or be similar) to the config requirements of the
> builds (which also needs some cleaning BTW).
Yes, but I do not know what information you want to store for hbmk2.
Probably full list of libraries used to create harbour shared library
libdynhas=hbextern hbvm hbpp hbrtl hbrdd rddfpt rddcdx rddnsx ...
will be better then separated entries like:
libdynhas=gtxwc
libdynhas=gtcrs
libdynhas=gtsln
maybe also it's good to set default system libraries in hbmk.cfg, f.e.
sth like
syslibs=...
You can also think about keeping all build time settings in separate
section like [default] or [build], f.e.:
# Harbour Make configuration
# Generated by Harbour build process
[default]
arch=linux
comp=gcc
gtdef=gttrm
It will be easier to add other sections for cross compilation.
> CCPATH and CCPREFIX are already supported by hbmk2,
> LIBDIR is HB_LIB_INSTALL, HARBOUR ~is HB_BIN_INSTALL.
> The rest can be passed as .hbp configuration (PRGFLAGS=).
> I don't want to develop an .ini engine, and the one in core is
> very weak, so maybe using simple .hbp files for this purpose
> could help (or some other flat format), with some new values
> are added.
> I have to think about it, but only after closing all current
> features. I'm waaay over all my time/energy budget right now.
Closing the basic functionality as the main goal is very reasonable
for me. I'm also waiting for it to start some real life tests.
> The next thing which should also be addressed is support for .clp files
> > in Harbour compiler. Now it partially works as hbmk2 scripts but here
> > one thing should be changed. hbmk2 should always add en extension if
> > not given to @script. Otherwise on platforms which does not use .exe
> > extension it begins to read final binary application as scripts if it
> > has the same name. I hope it's a minor problem and can be easy fixed.
> I've committed a patch to add extension .hbm to extension-less
> @ filenames.
Thank you. Let's leave it in this form now.
> The bigger problem is support for .clp files in compiler which is not
> > Clipper compatible and should be fixed but this needs serious modifications
> > in generated .c and .hrb files. I hope it will be fixed later so now
> > we can leave it as is.
> As for .clp, I don't know, never used them, couldn't find docs about the
> format or details about it. So we can do two things: Either drop it for
> hbmk and offer .hbm as a superior replacement, or (if we get to know
> the format details), we may write a parser for .clp files. Here the problem
> we have is that hbmk2 doesn't know if a @ option refers to an .hbm or
> a .clp if no extension is passed.
> Finally, maybe .clp is already parsable by .hbm parser... For the basic
> case it seems to be, but I don't know the .clp format enough to tell
> precisely.
> Since you say "serious modifications in compiler", maybe it's more than
> just parsing. Again, never used .clps (or at least I cannot remember when
> ;).
> So, I'm not sure that precise .clp support is very important for hbmk,
> maybe not even for Harbour.
The main problem with .clp files is the fact that clipper compiles
all defined .prg files separately but result it single .obj file.
The .clp functionality can be also accessed from pure .prg code by:
DO <filename> [WITH <args,...>]
statement or:
_PROCREQ_( <filename> )
or:
_PROCREQ_( <filepart1> + <filepart2> )
It's standard Clipper behavior.
In all cases Harbour does not support it well. The main problem
is the fact that static functions with the same name can exists
in different files and should not cause any conflicts. To resolve
this we will have to intorduce to C files new static function declaration,
f.e.:
#define HB_FUNC_STATIC_V( funcname, module ) \
static HARBOUR HB_FUN_##funcname##v##module( void )
of course the internal compiler logic should also be updated to play
well with different functions using the same name. Additionally we
should also resolve the problem with multiple file wide declarations
because when -n option is used then each compiled file has it's own
file wide variables.
This functionality was never implemented neither in Harbour nor in
xHarbour. I wanted to make sth with few times and in the last weekend
I even started but when I begin to check the code I've found some very
serious problems with statics and I had to invest time to resolve it.
To make it well it's necesary to change internal format of .c files
(it's minor problem for users) but also binary format used for .hrb
what will force also HVM modifications. I keep in mind that we should
add new .hrl/.hre files so probably I should join the modifications
but I do not know when :-(
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
