>> Maybe the only generic way to integrate such needs with
>> hbmk2, is to create an separate external tool (non-hbmk2)
>> and call it as part of of 'preprocessing'. So what needs
>> to be done in hbmk2 is to allow to run external tools at
>> specific stages of the process, f.e. 'preflight',
>
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
> 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
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
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
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
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
>> 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.
> 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
> 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
>>> 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
>> -env is not meant to suppress defines, but envvars.
>> To suppress a define, use '-under:__MT__' Harbour
>> option.
>>
>
> Probably it is '-undef:__MT__'.
Yes, typo. It's in Harbour help anyway.
>>> #ifdef __MT__
>>> #include "hbthread.h"
>>> static PHB_ITEM s_pMtx = NULL;
>>> #endif
>>>
>
> hbgetenv.c
>
>
> HB_BOOL hb_setenv( const char * szName, const char * szValue )
> {
> #if defined( HB_OS_WIN )
> {
> LPTSTR lpName = HB_TCHAR_CONVTO( szName );
> LPTSTR lpValue = HB_TCHAR_CONVTO( szValue );
> HB_BOOL bResult = ( SetEnvironmentVariable( lpName, lpValue )
> 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
___
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
>> hbmk2 will sort the input files by type
>> (looking at the extension), and use them
>> accordingly. It's true there is no negative
>> filter for headers though, and the reason
>> is that also harbour compiler doesn't limit
>> the compilable set of extensions this way.
>> (IOW you can do: 'h
Hi,
>>ENDIF
>> ENDIF
>> ENDIF
>> ---
>>
>
> I made experiments with above settings and code,
> but I could never pullout the executable. To be on the simpler
You have ": " before it and some sort of EOL after it.
What was the problem? I can't see any reason why changing
these to [
>> FOR EACH tmp IN aFiles
>> IF " " $ tmp
>> cFile += Chr( 34 ) + tmp + Chr( 34 ) + hb_osNewLine()
>> ELSE
>> cFile += tmp + hb_osNewLine()
>> ENDIF
>> NEXT
>> RETURN hb_memoWrit( cFN, cFile )
>> ---
>>
>
> Exactly.
>
> My point was only that SOURCES will al
>> speedtst.prg
>> ---
>>
>> The parser I wrote for hbide, will recognize the
>> source parameters, so there is not need to mark them
>> with '[SOURCES]'.
>>
>
> Ok, I understand now.
> But what if anything after -3rd= is ignored. I mean the lines containing
> the token at begining with -3rd a
> And here is the screen portion of hbMK2 -help:
>
> -ldflag=pass flag to linker (executable)
> -aflag= pass flag to linker (static library)
> -dflag= pass flag to linker (dynamic library)
> -runflag= pass flag to output executable when -run option is used
> -3rd
while my file hwgui.lib is recompiled if I call:
c:>\project\hbmk2 sciwin.hbm
It don't relink the new lib. :(
Try dropping .lib extension from -l options.
They are unnecessary and may break the process
depending on the compiler you use.
[ See hbmk2 --help about that at -l option description. ]
If
On Sun, May 17, 2009 at 1:42 PM, Massimo Belgrano wrote:
> You can't support .lib extension on linux platform?
>
No, I don't like to change input names provided by users.
Such hidden logic can create more problems than it solves
especially on the long run. Consider that in this case we
should als
You can't support .lib extension on linux platform?
>
> Just one comment:
>
> Using .lib extension works, but isn't recommended, because
> it creates non-portable command lines.
>
> Brgds,
> Viktor
>
>
> ___
> Harbour mailing list
> Harbour@harbour-proje
>
> Ok. The main thing, which is unclear for me from the help is about
> scripts.
> What are .hbm files, are they different from .hbp ?
1) .hbm is simple the extension of the command line, same
rules, same content, similar to many tools' @script functionality.
It serves (just like command line)
Thanks.
On Sun, May 17, 2009 at 9:19 AM, Massimo Belgrano wrote:
> I am working on italianthis is a preview
> Using hbmk2
> hbmk2 is a Tool that allow compile sample and large project
> basic use of this tools is
> hbmk2 ac_test
> hbmk2 ac_test.prg
> After this command you have ac_test.exe create
I am working on italianthis is a preview
Using hbmk2
hbmk2 is a Tool that allow compile sample and large project
basic use of this tools is
hbmk2 ac_test
hbmk2 ac_test.prg
After this command you have ac_test.exe created
You can also immediaply execute simple using
hbmk2 ac_test -run
Hbmk2 is indip
>
> Is there any important feature still missing from hbmk2?
>>
>>
> Yes - documentation :), at least, very basic.
Quite true, we have the -help option though. Writing comprehensible
docs isn't my strongest side, so I'd appreciate if someone could contribute
something in this area. I can help in
47 matches
Mail list logo
