Hi Przemek and all,
I've implemented almost all your requests by now (at
least I tried), so if you can invest some time in it I'd
appreciate your feedback very much. [ First I recommend
reading the relevant ChangeLog entries. ]
Of course I'd equally invite everyone on any platforms,
with any compi
On Thu, 19 Feb 2009, Szak�ts Viktor wrote:
> Let me include here our conversation from autumn I was referring to,
> back then the situations looked cleaner than what it seems now:
[...]
> -- vszakats says:
> No, if possible let's please remove -n1 and keep only -n/-n-.
>
OK. When hbmk2 will b
Hi Przemek,
> Use .a files just like .o ones and pass them to compiler as is.
> It will now what to do with them.
This is in SVN already. For -l I'm stripping all extensions,
not just dll/so/a. Pls tell if this is a problem, and I'll solve it.
> Yes it also supports it. DJGPP LD has also uses
Hi Przemek,
> > I know, but this isn't a Linux tool :) For Linux it isn't hardcoded,
> > just the default is set to gcc. You can set it just like for hbmk
> > script HB_COMPILER=gpp|owatcom. The new command
>
> For hbmk script I do not have to set anything because it's build
> dynamically in inst
On Thu, 19 Feb 2009, Szak�ts Viktor wrote:
Hi,
> Right now every filename passed as is (without -l) with the
> extension .a is considered a library. Would it help if hbmk would
> simply handle .a files just like object files? This would mean
> that libs with .a ending must have to be passed with
On Thu, 19 Feb 2009, Szak�ts Viktor wrote:
Hi,
> I know, but this isn't a Linux tool :) For Linux it isn't hardcoded,
> just the default is set to gcc. You can set it just like for hbmk
> script HB_COMPILER=gpp|owatcom. The new command
For hbmk script I do not have to set anything because it's b
Hi Przemek,
(answers part 2)
> > > 8. When -l gcc option is used then should
> > > not contain prefix (lib) and extension (.so,.dll,.a)
> >
> > hbmk does pass the stripped lib name to gcc -l option
> > already. The extension is already stripped (all of them,
> > maybe that's too harsh?). So i
Hi Przemek,
> Now in Linux is 100% predictable - GCC is hardcoded as the only
> one choice :-( and it's necessary to use HB_COMPILER envvar.
> BTW -cc= option will be also usable feature.
I know, but this isn't a Linux tool :) For Linux it isn't hardcoded,
just the default is set to gcc. You c
On Thu, 19 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> I intentionally created a fully platform neutral source and
> executable (except two minor exceptions). So that an hbmk.exe
> created with one compiler can easily be used to build with
> any other compiler. It creates a cleaner situation. To
Hi Przemek,
> 1. the C compiler auto detection should be extended to use also
> compiler used to compile Harbour.
> This is peace of code I was using from my hb-tools.prg:
>
> if empty( s_hb_compiler )
> cEnv := getEnv( "HB_COMPILER" )
> if !empty( cEnv )
>s_h
Hi Viktor,
I've just tried hbmk2.prg and I have few notes about it.
1. the C compiler auto detection should be extended to use also
compiler used to compile Harbour.
This is peace of code I was using from my hb-tools.prg:
if empty( s_hb_compiler )
cEnv := getEnv( "HB_COMPIL
11 matches
Mail list logo
