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 install phase from user settings.


If this is the preferred method for Linux users, we can easily
do it by extending compiler detection from hb_compiler() and
tweaking the currently static default based on that. How does
this seem for you?


> I think that here we have yet another mistake. Probably someone send
>  you some very old hbcc description. In RPMs and in doc/howtobld.txt
> we have:
> ,---------------------------------------------------------------------
> | "hbcc" is a wrapper to the C compiler only. It sets all flags
> | and paths necessary to compile .c files which include Harbour header
> | files. The result of its work is an object file.
> `---------------------------------------------------------------------


'hbmk -hbcc' will work as you say, given that you don't supply
any .prgs on the command line. If this isn't good enough we
can further tweak it to better emulate hbcc.


> > I'll add -info switch which will control currend OutStd()
> > messages, these will be kept 'on' until we test hbmk,
> > later turned off. -q will disable informational messages
> > + logo.
>
> But -q is also harbour compiler switch so I cannot control them
> separately.


Since harbour was called with -q0 anyway, this didn't
seem like a big problem, anyhow I've changed it to -quiet to
clear this up, and allow us to play with -q0.


> > >   // t.prg
> > >   ? "Hello World!!!"
> > > hbmk t && ./t
> > Is this also true on Windows? all compilers? I'd love to
> > see it working like this on all platforms/compilers, and in
> > this case we can safely remove -n.
>
> It is and always was in the whole [x]Harbour history I remember.


Good then. I remember otherwise from the early times,
and I might have missed something along the way, which
is good. Since we currently have _all_ Harbour tests and
samples using MAIN() entry points, we will have to find
a solution to let these compile easily. .hbp files could
help. If you have a suggestion, I'd appreciate it. [ maybe
entry point detection? ]


> > What about the -n1 situation? Is it possible to add those
> > discussed changes?
>
> I think that we should finish one thing 1-st. I have not idea what will
> be the final result of hbmk2.prg usage in different platform and for
> cross compilation so I'd prefer to leave it as is.


Ok.


> > Which it does, but it was so obvious I didn't include
> > in my answer.
>
> It's very hard to guess what is obvious for you.


Since without -I you don't have a chance to compile
any Harbour .prgs using .ch files, so it should be there,
just like -I for C compiler, I thought this is obvious. You
could have peeked into the source, which I thought you did ;)


> -n and -q wasn't for me.
> Just like this:
>   TODO: Add support for wildcarded input source.
>         Only if only one source file is specified.
> is obvious technical nonsense for *nix users ;-)


What is *nix? :) But seriously, thanks for reminding me,
anyway non-*nix users might find this useful still. The
TODO isn't clear but I meant to generate multiple .exes
in such case. This feature would need quite some work
with not terribly big use except compiling test dirs, so
I'll see, it's not top priority.


> Here we should also add something to change path base path
> logic detection because link can be in different directories
> then hmmk2 binaries. We should add support for passing some


Your help here will be needed here.


> build time switches, f.e. we have to decode HB_PCRE_REGEX
> and HB_EXT_ZLIB build time macros to use native platform pcre
> and zlib binaries.


I've implemented some bits of this. Tell me if something
is missing still.


> Probably hbmk2.prg auto detection logic should be changed.
> 1. default compile time mode - used by 99% of users which
>   strictly keep the same platform and C compiler as the
>   one used to create hbmk2 binaries. It's very seldom
>   situation when user will want to use harbour.exe/hbmk2.exe
>   compiled by different C compiler then the one used to compile


Speaking about non-*nix, to make everyone happy, we can
add a switch to influence autodetection, and allow to turn on
chameleon mode where it would behave like what it was
specifically built for.

Anyhow in prinpical here I very strongly disagree, for non-*nix systems.
I think this is more than unexpected behaviour in this world. I can
understand why you need it on *nix, but here this is completely
alien, I've never ever seen such, maybe with the exception
of some *nix rooted tools, and they've made life very difficult
when working with them, their behaviour very difficult to predict,
just to name two from the life of Harbour: make.exe, bison.exe
for many years. And this is still present with some ported
tools. We shouldn't replicate this with Harbour tools, and
we don't do this for harbour.exe either, very very luckily.


>   harbour libraries. Such situation happens only during cross
>   compilation. In fact also using different C compiler for the
>   same platform should be treated as some type of cross compilation
>   because binary libraries in most of cases cannot be moved between
>   compilers and even if final executable files can be created then
>   there is very big chance that it will be corrupted due to difference
>   in CRTLs. I also do not believe that many users will try to collect

  manually final Harbour installation from two different binary builds
>   and hbmk2.exe will come from the 1-st one and libraries from the second
>   one. It's unusual situation and any auto detection which will prefer it
>   will only create more troubles by sporadic wrong compiler detection
>   due to differences in environment settings.


While I agree with what you say, it's still fundamentally against
all non-*nix tools to do such thing. In this case we should at least
change the name of the .exe to make it clear that while all of them
look the same, feel the same, they indeed completely different tools
internally. Such thing would nix the possibility to put hbmk.exe
in the path and let do it's job neutrally for different Harbour dirs
explicitly specified with HB_INSTALL_PREFIX envvars. Not to
mention the case of simply copying hbmk.exe around to another
build and try to use it there, to much surprise.

So to sum it up I'd propose a switch to select free autodetection
like now, and fixed compiler detection based on build. In this
case I'll remove current hack to prioritize based on build.
For *nix system the build based method will be the default
for non-*nix build the former.

So much for simplicity, but what can we do.

  In this mode hbmk2.prg should fully respect compile time macros
>   like HB_PCRE_REGEX, HB_EXT_ZLIB, HAVE_GPM_H, etc. It may also
>   detect default GT driver and not overload it if it's not strictly
>   necessary though it's minor feature.


Same issue as above. I wouldn't abuse flag inheritance on
non-*nix too much, it's dangerous and not overly useful.
Except for prg flags.

Other than that we can detect these settings and apply for
platforms where this is expected and useful (*nix mostly).
The only current exception is the GT driver, if it was overridden
at build-time. For the GT issue, we can add a hb_version() readout
about the default state, but overall I'm not a big fan of GT override
at build time. After all it can be changed anytime dynamically.
It's like wanting to set the default RDD at build time. It just
creates problems. IMO.


> 2. support for cross compilation where we can chose other then default
>   C compiler.
>   In such case it will be also necessary to set different library path
>   (in few seldom situations maybe also include path), (un)define some
>   harbour compiler macros using -D/-undef: options, set C compiler prefix
>   and/or some C compiler options. It will be hard to create full
>   auto detection for all possible combinations so user will have to
>   control each setting manually. To make it easier I suggest to intorduce
>   config file which will have sctions like in .ini file. Each section
>   will contain full information necessary to pass succesfully cross
>   compilation, f.e.:
>         [xmingw]
>         COMPILER=mingw
>         CCPREFIX=/usr/local/bin/i386-mingw32-
>         PRGFLAGS=-D__PLATFORM__WINDOWS -undef:__PLATFORM__UNIX
> -undef:__PLATFORM__LINUX
>         ...
>   such file is easy to edit and it's not necessary to hard code all
>   information in different make file. It's also easy to copy and update
>   on different computer for different configuration. It's single file so
>   setting new environment is much easier. I hate when I have to update
>   xxx files and I forgot about some of them. After setting user can
>   easy specify 'xmingw' in some hbmk2 parameter and work with new
>   environment.
>

Yes, we need to solve cross compilation. But first I'd
like to clear the non-cross issues simply because I
cannot keep that many open threads in my head :)

For the cross compile thing, we'd need to find some
more generic solution than the current one. Even that
GNU-make settings are a bit unclean.

As for the config file, I'm not sure yet, it really starts
to push hbmk2 on the bloated/complicated side. We should
make it as light as possible and as easy to use as possible,
even for cross compilation. So, I'd prefer to hide cross platform
details (tools, logic) inside hbmk2, if there is any chance
for that. We could initiate a cross build by special arch | compiler
pairs: linux - mingwce, win - msvc64, we already have:
win - mingwce / poccce / pocc64. etc. So I'd try to add these
to the current structure.

Maybe what you say could be a way to override internal
rules in hbmk2. This can be interesting although very advanced,
and it would also need to create smooth easy to reconfigure
rules inside hbmk2. To make rules _fully_ configurable, it
would need a considerable amount of work to do it properly.

So in essence the current hard-wired .prg logic should be
separated to an external rule file + a rule processor.


> I do not see any reason why we have to hard code such limitation
> and forbid users to use hbmk also in make scripts. For me it's the
> main job of such tool and I do not expect that we will create make
> system comparable to GNU make in the nearest future.


We're circling around this topic, I'm not sure why,
probably we're misunderstanding each other. I've already made
several modifications to allow for this type of usage, plus this
was my intention right from the point I realized the need, and
I haven't by any means stated that I'd like to "frobid it". This
is nonsense, I have no idea where did you get this. So after
spending quite a time on it, now we have some modes which
focus on this kind of usage, and there is default mode which
focuses on normal (hbmk.bat-like) usage, and there are switches
to bend behaviour if defaults aren't adequate. Photocopying 100%
hbmk script behaviour isn't an option, as we have to deal with some
more aspect and more platforms, not to mention the possibilities
are also wider, so we should concentrate on what's important. If
you have some specific suggestions what to tweak to clear up
remaining ones, or why does it feel like it "forbids" anything,
please tell, but speaking in general I cannot do much more
than now.

I'd also invite you to try the tool out, I'm not sure if had
already done so :)

Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to