[Harbour] SF.net SVN: harbour-project:[11109] trunk/harbour

[Szakáts Viktor]

> The next thing is setting HB_INSTALL_PREFIX.
> Autodetection works until I'll do not use -comp=mingwarm switch,
> If I set it then I have message:
>   hbmk: Error: HB_INSTALL_PREFIX not set, failed to autodetect
> It's caused by .exe extension when hbmk2 looks for harbour binaries.
> Can you resolve it?, f.e. ignore auto detection when user forces cross
> compiling.

Okay, that explains it, I'll commit a fix for it a bit later today.

> The second interesting thing is -trace output. hbmk2 shows:
>
>   /home/druzus/CVS/harbour/out-cmg-tst/bin/harbour.exe -n2 hbmk2.prg \
>      -i/home/druzus/CVS/harbour/out-cmg-tst/include \
>      -undef:__PLATFORM__LINUX -undef:__PLATFORM__UNIX \
>      -D__PLATFORM__WINDOWS -D__PLATFORM__WINCE
>   Harbour 1.1.0dev (Rev. 11106)
>   Copyright (c) 1999-2009, http://www.harbour-project.org/
>   Compiling 'hbmk2.prg'...
>   Lines 6453, Functions/Procedures 80
>   Generating C source output to 'hbmk2.c'... Done.
>   hbmk: C compiler command:
>
> but /home/druzus/CVS/harbour/out-cmg-tst/bin/harbour.exe for sure
> cannot be executed because it's WinCE executable. I even removed
> whole /home/druzus/CVS/harbour/out-cmg-tst/bin directory and executed
>   hbmk2 -comp=mingwarm ...
> and it was working still printing above command.
> I guess it's result of some desynchronization between real executed
> commands and messages showed by trace. IMHO such things should be  
> fixed
> because they makes debugging very hard and hbmk2 always have to show
> real executed command.

What happens here is that hbmk2 uses its internal Harbour compiler
in all cases (except in -xhb mode), and it prints an *equivalent*
command line on screen (in case someone would like to copy it, or
just FYI). This cmdline might be misleading for cross-compilation
sessions. What I can do is first to fix the .exe extension, this
is easy, but the path could still be off (since external Harbour
executable isn't needed and may not be present at all). If this is
a problem, I can change this text to something else (like "(internal
compiler)") when cross-compiling is done. I'd vote to fix the
extension only.

Anyway it's just a cosmetic issue and it should properly compile
regardless.

Brgds,
Viktor