If we can define the rules when to include this lib I can add
it to hbmk2. First confusion is what is the difference between
supc++ and stdc++ ? mingw/win requires supc++ when linking hbqt.
i would rather say that if harbour was built with cpp mode, then
hbmk2
should call g++ (CXX) instead gcc (CC) automatically. "manually"
messing with this seems counterintuitive, no? this i believe also
would take care of stdc++ vs supc++ (no idea what the difference is),
libCrun on sunpro, and other c++ support libs other compilers might
have. i think.
IMHO hbmk2 by default should look for compiler used to compile hbmk2
and then look for others.
In most of cases it's used with the same compiler so it's preferable
behavior and any other combinations also needs to sync libraries.
So it's enough to check existing HB_VERSION_* flags.
Yes, it can be solved easily. It's rather a usability issue.
It will also resolve few other problems I have now, i.e. I cannot
use hbmk2 on computers where I have other C compilers in the PATH.
On which platform does this happen?
Maybe on *nixes this is good, but on non-*nix this would be a
disaster and I often praise the day I didn't implement it at
the end (well, actually removed some initial attempts based
on this same train of thought).
Now, if I start to make hbmk2 behave differently on different
platforms, things will start to become very cheesy. For one thing,
I won't be able to support it because it's simply impossible to
know why hbmk2 behaves the way it does.
Moreover, copying around hbmk2 executable would create all sorts
of "interesting" effects. Maybe this is not done often on *nix
systems, but anyway, on non-*nix it's usual, and it happens f.e.
when assembling the unified installer.
BTW what is current order/priority of detecting C compilers in hbmk2?
It's a little messy ATM. On *nixes there is no autodetection
when doing native builds, it will default to the C compiler
used to build hbmk2 itself (this what you ask for, so I wonder
why doesn't it work for you, but you didn't tell the platform).
For cross builds there is autodetection of cross-tools if you
specify target platform, there isn't if you specify target
compiler.
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).
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
