Don't offend me in any way. I totally understand you. Again maybe my poor
English sent wrong impression.
As I said *personally IF I am last Harbour user* I would drop a lot of
legacy, but I never would that thinking about the whole community.
[]'s Maniero
2010/5/14 Viktor Szakáts
> > It was
> It wasn't my intention make you reply that, I just do a statement trying to
> wide the view about the problem. As I wrote I completely agree about the
> whole decision and specially your last paragraphs as below. Maybe my poor
> English have been confusing about my message.
Sorry if message s
It wasn't my intention make you reply that, I just do a statement trying to
wide the view about the problem. As I wrote I completely agree about the
whole decision and specially your last paragraphs as below. Maybe my poor
English have been confusing about my message.
Please don't waste time on th
Hi,
> First of all, I support your decision, don't get me wrong. Maybe this
> statement be unnecessary.
>
> I can (guessing) understand what Massimo said. Some modern
> languages/development platforms allow this construction in a portable way
> (Java, CLR, Python, Ruby, even Delphi could), som
Hi Viktor
First of all, I support your decision, don't get me wrong. Maybe this
statement be unnecessary.
I can (guessing) understand what Massimo said. Some modern
languages/development platforms allow this construction in a portable way
(Java, CLR, Python, Ruby, even Delphi could), some better
> IMO A mingw solution will be good
It's not good because in Harbour we've a basic
goal to be _portable_.
> Mingw/GCC is most used C compiler in harbour
> I bad explain but i think it might be very handy to have inside main
> .prg one directive(s) about libraries inclusion.
> In first use of h
IMO A mingw solution will be good
Mingw/GCC is most used C compiler in harbour
I bad explain but i think it might be very handy to have inside main
.prg one directive(s) about libraries inclusion.
In first use of harbour user have two problem
- Wich library i must load?
- How resolve Unreso
>> About an idea of completely different implementation of pragma
>> I want remember that xbase++ support an intersting preprocessor directive
>> #pragma library ("mylib.lib")
>> Is possible implement also in harbour for minigw?
>> or at least adapt something like
>> #pragma BEGINDUMP
>>#pra
On Wed, 12 May 2010, Massimo Belgrano wrote:
Hi Massimo,
> About an idea of completely different implementation of pragma
> I want remember that xbase++ support an intersting preprocessor directive
> #pragma library ("mylib.lib")
> Is possible implement also in harbour for minigw?
> or at le
> I do not know if it will make-up in hnMK2,
> I understand your concerns, but the code below,
> and I am sure it has greater margins to be refined,
> if included in hbMK2 will solve the problem for
> applications which mix compile time switches
> in not an organized way. It also does not break
Viktor Szakáts wrote:
>
>
> I'll implement a trick to solve this for xhb users.
>
>
I do not know if it will make-up in hnMK2,
I understand your concerns, but the code below,
and I am sure it has greater margins to be refined,
if included in hbMK2 will solve the problem for
applications wh
> On Wed, 12 May 2010, Szak�ts Viktor wrote:
>> Is it not enough to select between -tWM / cw32mt and
>> -tW / cw32 based on the -st/-mt flag when in -xhb
>> mode?
>
> As I said it will break user custom builds which use -tWM flag to compile
> whole xHarbour code. Such users will have to use -mt
Viktor Szakáts wrote:
>
>> I've just check HBMK2 code and I do not know if Viktor can help you much.
>> In fact the problem is that xHarbour uses different switches for MT and
>> ST libraries and not all core libraries are compiled for MT mode. It
>> means that all xHarbour MT BCC binaries are p
On Wed, 12 May 2010, Szak�ts Viktor wrote:
> Is it not enough to select between -tWM / cw32mt and
> -tW / cw32 based on the -st/-mt flag when in -xhb
> mode?
As I said it will break user custom builds which use -tWM flag to compile
whole xHarbour code. Such users will have to use -mt HBMK2 switc
> I've just check HBMK2 code and I do not know if Viktor can help you much.
> In fact the problem is that xHarbour uses different switches for MT and
> ST libraries and not all core libraries are compiled for MT mode. It
> means that all xHarbour MT BCC binaries are potentially broken because
> the
Okay. So next question is in context of -xhb mode:
Should -tW / cw32.lib chosen when building in ST
mode, or should this be used permanently, or
is there some other logic to follow here?
Viktor
On 2010 May 12, at 20:54, Pritpal Bedi wrote:
>
>
> Przemysław Czerpak wrote:
>>
>>
>> It's com
On Wed, 12 May 2010, Pritpal Bedi wrote:
Hi,
> xMate compiles the same source as:
> [1]:Bcc32.Exe -D__xDEVELOPMENT__ -D__xCACHE2009__ -D -d -5 -6 -a8 -c -O2
> -tW -DHB_FM_STATISTICS_OFF -DHB_NO_DEFAULT_API_MACROS
> -DHB_NO_DEFAULT_STACK_MACROS -DHB_OS_WIN_32 -IInclude
> -IC:\Dev\BCC55\Include
On Wed, 12 May 2010, Pritpal Bedi wrote:
Hi,
> > It's completely unimportant which code exploited the problem in
> > visible way. Important is only that you are mixing files compiled
> > for ST and MT mode (with and without -tWM flag) during linking
> > final application and this is the source of
> This is probably the _REAL_ cause.
>
> I have checked, if not otherwise nullified, even if -st flag is
> sent to hbMK2, it always compiles C code as :
>
> bcc32.exe -c -q -tWM -d -6 -O2 -OS -Ov -Oi -Oc -w -Q -w-sig-
> -nE:\dev_hbmk\xharbour\obj\cacherdd -IC:\xharbour\include
> -ID:\Projects\Ca
Przemysław Czerpak wrote:
>
>
> It's completely unimportant which code exploited the problem in
> visible way. Important is only that you are mixing files compiled
> for ST and MT mode (with and without -tWM flag) during linking
> final application and this is the source of your problem.
> All
In continuation...
Pritpal Bedi wrote:
>
>
> Przemysław Czerpak wrote:
>>
>> It's completely unimportant which code exploited the problem in
>> visible way. Important is only that you are mixing files compiled
>> for ST and MT mode (with and without -tWM flag) during linking
>> final applicat
Przemysław Czerpak wrote:
>
> It's completely unimportant which code exploited the problem in
> visible way. Important is only that you are mixing files compiled
> for ST and MT mode (with and without -tWM flag) during linking
> final application and this is the source of your problem.
> All wha
On Wed, 12 May 2010, Pritpal Bedi wrote:
Hi Pritpal,
> >> > I thought that you want to introduce full separation of compiled
> > the #pragma low level behavior strictly depends on
> > current compiler implementation. It may change in
> My current requirement is to just get rid of the unresolved
Viktor Szakáts wrote:
>
>> BTW we can also introduce #pragma push/pop which can be used
>> by user to resolve the problem of interaction between compiler
>> switches in much more flexible way.
>
> It's very good idea. Maybe it even makes the per file
> issue easier to fix, since it's possible
Hi Przemek,
> the #pragma low level behavior strictly depends on
> current compiler implementation. It may change in
> the future or may need some completely different
> implementation for modified compiler code so it should
> not be sth what we can define as strict part of language
[snip]
> If yo
Hi Przemek,
About an idea of completely different implementation of pragma
I want remember that xbase++ support an intersting preprocessor directive
#pragma library ("mylib.lib")
Is possible implement also in harbour for minigw?
or at least adapt something like
#pragma BEGINDUMP
#pragma c
Przemek
Przemysław Czerpak wrote:
>
>> > I thought that you want to introduce full separation of compiled
>
> the #pragma low level behavior strictly depends on
> current compiler implementation. It may change in
>
My current requirement is to just get rid of the unresolved
external "_errno
On Wed, 12 May 2010, Szak�ts Viktor wrote:
Hi Viktor,
> > I thought that you want to introduce full separation of compiled
> > PRG modules specified at command line so hbmk2 which now passed
> > all prg modules to harbour compiler in single call can be safely
> > used without any interactions bet
Hi Przemek,
On 2010 May 12, at 12:33, Przemysław Czerpak wrote:
> On Wed, 12 May 2010, Szak�ts Viktor wrote:
>
> Hi Viktor,
>
>> My only concern is #pragmas. Here compatibility
>> doesn't apply as Clipper didn't have them.
>>
>> Do you think it can be fixed to reset the #pragma
>> settings t
On Wed, 12 May 2010, Szak�ts Viktor wrote:
Hi Viktor,
> My only concern is #pragmas. Here compatibility
> doesn't apply as Clipper didn't have them.
>
> Do you think it can be fixed to reset the #pragma
> settings to initial state after compiling each
> separate source file?
Probably yes but
Hi Przemek,
>> I hope Przemek can take an expert look on this issue,
>> as I'm sure it's not intentional that such options are
>> changing across sources. F.e. this causes unpredictable
>> results for anyone using 'harbour *.prg' on a *nix
>> system f.e. These pragmas are meant to be per file.
On Tue, 11 May 2010, Szak�ts Viktor wrote:
Hi,
> > Then I searched the sources for #pragma directives.
> > Because I am not the author of those sources, I never knew that
> > multiple #pragma directives were in use. And that was the potential
> > reason to get thousands of warnings which ultimate
>>> I am compiling/linking a extremely large project
>>> with hbIDE, hbMK2 ( hbMK2 is slightly modified to supply
>>> sources to Harbour compiler one-by-one, rest remaining the
>>> same as is ) with -xhb switch.
>>
>> Too bad, this way we will never know what the real problem is.
>> Did you rea
Viktor Szakáts wrote:
>
>> I am compiling/linking a extremely large project
>> with hbIDE, hbMK2 ( hbMK2 is slightly modified to supply
>> sources to Harbour compiler one-by-one, rest remaining the
>> same as is ) with -xhb switch.
>
> Too bad, this way we will never know what the real probl
Pritpal Bedi wrote:
>
> In continuation...
>
> "Hello World" prg buils fine with -lgtwin.
> The compile and link flags are the same as of
> larger application.
>
> So where is the catch?
>
Any clues guys ?
I am struck to this very fact and appears to be
a show-stopper to implement hbIDE in
In continuation...
"Hello World" prg buils fine with -lgtwin.
The compile and link flags are the same as of
larger application.
So where is the catch?
Note that there are few .C sources and
few .prg sources also contain C code.
Any help is appreciated.
-
enjoy hbIDEing...
Pr
36 matches
Mail list logo
