On Wed, 04 Mar 2009, Szak�ts Viktor wrote:
Hi,
> > -c is C compiler option. Not hb* script.
> > hbcc doen not have assume any result of final build.
> > If this is a problem for you to separate internal hbmk2
> > compile time and link time logic then look of -c C compiler
> > switch. If it's not a problem then forget about -c and simply
> No, it's already separated. This (-c) functionality was originally
> covered by -hbcc switch, and the one with linking is the default
> (still is).
> > make it working.
> > I only want to have working hbcc which can be used to compile
> > or link .c/.o/.a files just like C compiler.
> See my more recent reply on this. I have a patch pending (attached)
> which accepts -c in -hbcc mode to create the "stopafterccompiler"
> effect. I'm thinking of adding some cleaner (non-compatibility)
> switches to achieve these effects, but this isn't urgent.
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.
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.
When the basic hb* script functionality will be replicated then
the next step is support for cross compilation.
Now hbmk2 for compilers shows:
linux : gcc, gpp, owatcom, icc, mingw, mingwce
mingw and mingwce are not Linux. It's only one of posisble cross
compilation. Create Windows or WindowsCE binaries in Linux if
MinGW* environment is installed. There are different ports of
MinGW*, f.e. for BSD or Darwin so it should not be bound with
Linux directly though if for some reasons its easier for your
then we can keep it in such way but it should be added also to
other *nix based builds.
I think that it will be better to implement some more general
solution which will have:
1. support for C compiler prefix
2. PATH expansion (HB_SETENV())
3. default harbour compiler switches like:
-D__PLATFORM__WINCE
-D__PLATFORM__WINDOWS
-undef:__PLATFORM__UNIX
-undef:__PLATFORM__LINUX
It will be nice if all such settings for different cross compilations
can be grouped in single hbmk.cfg file, f.e. sth like:
[mingw]
ARCH=win
CCPREFIX=i386-mingw32-
PATH=/opt/xmingw/bin
HB_OPT=-undef:__PLATFORM__UNIX -undef:__PLATFORM__LINUX
HB_OPT+=-D__PLATFORM__WINDOWS
LIBDIR=/usr/lib/harbour-win
HARBOUR=/usr/bin/harbour
[mingwce]
ARCH=win
CCPREFIX=arm-wince-mingw32ce-
PATH=/opt/mingw32ce/bin
HB_OPT=-undef:__PLATFORM__UNIX -undef:__PLATFORM__LINUX
HB_OPT+=-D__PLATFORM__WINCE -D__PLATFORM__WINDOWS
LIBDIR=/usr/lib/harbour-wce
HARBOUR=/usr/bin/harbour
and accessed by single hbmk2 parameter, f.e.:
hbmk2 -comp=mingwce ...
It should help to set different cross compilation environment for GCC
based compilers without updating hbmk2.prg code. I haven't look deeper
at OpenWatcom cross compilation but seems that it should be also possible
to configure it in such way.
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.
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.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
