Hi Przemek,
I'm really sorry but I was wrong. I've just tested current SVN
and default build time CC is preferred.
I'm "nearly" sure that few weeks ago it was a problem and I had to
update my build scripts, i.e. OpenWatcom was preferred when I had
This feature works this way since the early days of hbmk2 for
*nix. There are many scenarios, so it's possible you've seen
it in a slightly different one.
in my envvars:
export WATCOM="/home/nwe/lng/watcom"
export INCLUDE="${WATCOM}/lh"
export PATH="${WATCOM}/binl:$PATH"
Now this happens only in pure Harbour build system (make) but I can
leave with though I'm not sure it's good choice for default behavior
because we will chose some rather platform exotic compilers if they
are installed instead of system default one.
If someone added an exotic compiler to the beginning of the PATH
IMO it must have been done for a reason. This is one difference
between hbmk2 and GNU Make, former doesn't do compiler autodetection
in this case, exactly because it's normal to have multiple ones
in PATH on *nix systems. I hope to be able to settle with some
behavior which makes most users happy, and then I'll be able to
sync hbmk2 and GNU Make.
Current hbmk2 behavior is OK for me - thank you very much and I think
we should only add support to "inherit" C++ mode from Harbour build
settings.
I'd resist here. Certainly not a good idea on non-*nix
(additional question: should watcom and msvc built hbmk2
compile in C++ mode by default too?), which makes it rather
odd to implement for *nix only (another additional question:
how to behave in cross-compile mode in this regard?). I've
made some steps which makes it possible to use HB_BUILD_MODE
envvar to control that aspect in a nice way, maybe it could
help to solve this.
BTW you or Tomaz asked about using OpenWatcom in Linux. Current
version
(1.8) in full installation contains binaries for DOS, WIN, OS2 and
Linux builds. It's enough to set executable attributes for Linux
binaries in ${WATCOM}/binl directory.
Thanks, it works like this on all platforms, so I assumed it works
similarly on Linux, but I've yet to install it in my Linux env to
watch it in action. (I have it on DOS and Win, plus setup all
possible cross-platform mode)
On non-*nix there is autodetection for most native compilers
(some, like pocc64/poccarm are missing yet). If none can be
detected, it will look for embedded installations based on
target platform. It will also look for embedded installations
if user explicitly selected the compiler.
You can check the order of detecting different compilers in
variables aCOMPDET and aCOMPDET_EMBED.
I plan to rework autodetection to solve all current problems
in an easier to oversee way, current state is rather organic,
and misses some extras we have in GNU Make (although it has
others).
Addressing all issues is horrible problem. Now you collected most
of information so you can try to create some more common and simple
rules which can be easier to guess/follow by users what I agree is
very important. Anyhow it's still huge job and thank you very much
for your all affords and final results which are fantastic.
Thank you for the compliment.
I agree with that and by now we probably know if not all, but
most quirks we have to deal with. Probably time for a refactor :)
Well, I don't plan such thing, but eventually I'd like to touch
at least the autodetection part. Later maybe we can think about
generalizing the internal setup, but that looks quite though.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
