>> Moreover, if someone wants to do this (per source
>> options), there are other, already working ways to
>> solve it. (f.e. defines, and pragmas). This are
>> make-system agnostic, part of the source code, thus
>> much better.
>>
>
> #pragma could be a solution and have tested and works ok.
Viktor Szakáts wrote:
>
> So you went along and implemented what I intentionally
> didn't want to implement.
>
> If time is a factor for you and you cannot wait to
> find the proper solution, pls keep above patch local
> to your system.
>
Of course, local.
> I don't agree with such feat
> Well I did some experiments and here I get the solution ( though temporary )
> until the issue is resolved:
>
> hbmk2.prg [ #3972 ]
>
> #if 1 /* Original */
[snip]
> #if 0
> next
> #endif
So you went along and implemented what I intentionally
didn't want to implement.
If time is a factor for
Viktor Szakáts wrote:
>
>> To be on the quicker side, and if it can be acieved easily,
>> can you provide functionality to call Harbour.exe for each souce
>> separately controllable through some switch, i.e., -componebyone=yes.
>
> No sorry, I'd like to find the real solution.
>
Well I did s
> No, it is not hbMK2 bug at all.
> It is Harbour compiler's bug which starts dumping warnings
> after a certain limit of confronted warnings are reached.
> It can be illustrated like this:
> (code - sephagatti - compilable with minimum warning level )
>
> a.prg -> 2 lines code; 11000 warning
Viktor Szakáts wrote:
>
>> Any clues?
>
> To me it looks like a regular problem, not
> some kind of bug.
>
> If you think hbmk2 is the suspicious piece one here,
> simply try the harbour cmdline (printed by -trace) directly.
>
No, it is not hbMK2 bug at all.
It is Harbour compiler's bug wh
>>> To be on the quicker side, and if it can be acieved easily,
>>> can you provide functionality to call Harbour.exe for each souce
>>> separately controllable through some switch, i.e., -componebyone=yes.
>>
>> No sorry, I'd like to find the real solution.
>>
>
> Any clues?
To me it looks li
Viktor Szakáts wrote:
>
>> To be on the quicker side, and if it can be acieved easily,
>> can you provide functionality to call Harbour.exe for each souce
>> separately controllable through some switch, i.e., -componebyone=yes.
>
> No sorry, I'd like to find the real solution.
>
Any clues?
> Hello Viktor
>
> To be on the quicker side, and if it can be acieved easily,
> can you provide functionality to call Harbour.exe for each souce
> separately controllable through some switch, i.e., -componebyone=yes.
No sorry, I'd like to find the real solution.
Viktor
___
Hello Viktor
To be on the quicker side, and if it can be acieved easily,
can you provide functionality to call Harbour.exe for each souce
separately controllable through some switch, i.e., -componebyone=yes.
I really need this issue be solved fast.
-
enjoy hbIDEing...
Pritpal
Viktor Szakáts wrote:
>
> -w0 only changes Harbour warning level. To turn off
> C compiler warnings, you can use -warn=no option, by
> default hbmk2 uses the same warning level as Harbour
> build and bcc is known to exit with fatal error if
> number of warnings is high. I'd suggest to experi
Hello All
Below are the hbIDE logs ( for this matter, it is the same if it is executed
on command line ).
The MOST puzzling factor is that if I put "C:\Dev\C5\cn.prg" after
"C:\Dev\C5\ar.prg" the
the above warnings are shown for "C:\Dev\C5\VR.PRG".
The behavior is the same for Harbour latest
Hi Pritpal,
> But now I have run into another issue and am at a loss to
> determine what causes this behavior. This is one very large
> production project which is always linked through xMate and BCC55.
> xMate issues compiler commands per source file and all goes absolutely
> ok. Now I am tryng
Viktor Szakáts wrote:
>
> Or use '-n-'.
>
-n- resolves this issue.
But now I have run into another issue and am at a loss to
determine what causes this behavior. This is one very large
production project which is always linked through xMate and BCC55.
xMate issues compiler commands per sourc
14 matches
Mail list logo
