I do not talk about such situation. I'm talking about situations
when some exotic compilers are installed in system paths like
/usr/bin and comes out of the box in some devel distributions
or simply system administrator like it.
As result to create most commonly used binaries we have to
use explicitly HB_COMPILER variable. And in some case like
creating RPMs we always have to set it or in some systems
it will not be possible to create native packages at all.
Okay, I understand.
It's also a problem for darwin now (clang vs gcc).
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.
Now we reach the following effect:
"If you are using some *nix system and you do not exactly know
what comes with default distribution or what admin installed
(or even you unintentionally downloading all devel packages)
then always use HB_COMPILER variable to be sure you create system
compatible binaries. Suggested HB_COMPILER values for different
*nix systems are:
OS COMPILER
... ...
"
If it was your goal then you can add such description to INSTALL file
but for me it's not good default behavior.
I think it all comes down to the order in which compilers
are detected. The other option is to delete autodetection
on *nix hosts (like it is the case with hbmk2). Deleting might
seem a bit harsh, so maybe we should just tweak the order.
My thought was that watcom/sunpro/icc are currently optional
components on Linux (not available as std pkg AFAIK), so if
it's in the PATH, it's highly likely the user put it there
manually, so that it be used. Same thinking goes for sunpro
on sunos. Or to put in another way: gcc is installed on
these platform (at least on Linux) most of the time, so
if I put it to the top of autodetection, it's very unlikely
the others get ever detected.
So what should be the right thinking here? We can reorder
them any way we like, question which is the most convenient
in real life. (or delete)
This way INSTALL could hold the list of supported C compilers
in order of autodetection preference.
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.
I suggest to use it with compilers which needs it, i.e. GCC based
compilers which needs different CRTLs. On some platforms it may not
be possible to link with CRTL C++ code so without inheriting
C++ switch hbmk2 will not work.
Anyhow I do not need such functionality personally so I'm leaving
decision about default settings to you though it will be nice if such
default settings can be modified in hbmk.cfg.
It's possible to control it from hbmk.cfg, using 'cpp=[yes|no|def]'
line.
I'll try adding supc++ lib to liblist for gcc compilers and
see what happens.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
