From: Jim Douglas (jim_at_[hidden])
Date: 2006-02-14 05:16:30
Vladimir Prus wrote:
> On Monday 13 February 2006 14:35, Jim Douglas wrote:
>>Vladimir Prus wrote:
> Ok. I've looked at qcc.jam and it looks very much like gcc.jam. Given that
> gcc.jam is pretty solid, I'd expect little problems except where QNX's gcc
> differs from stock gcc.
> However, maybe just inheriting from the gcc toolset would be better? We can
> always remove the inheritance if it provides problematic for future
> extensions, but if we start with a verbatim copy of gcc.jam it's very likely
> that changes in gcc.jam will never make it into qcc.jam, even if applicable.
OK, go ahead...
>>>>- two compilers GNU gcc & Intel, with versions of both.
Forget about Intel, it is only available on a Windows hosted development
system and (later) we can try using one of the generic Intel toolset
'.jams' as a starting point. So that just leaves gcc and variants
>>>>- two C++ standard laibraries GNU & Dinkumware with sub-variations
Just concentrate on GNU (stdlib=default) and Dinkumware (stdlib=dinkum).
The major variations are abbreviated and embedded which may not work
with Boost at all.
>>>>- self hosted (native) compilation on QNX
>>>>- cross compilation on Windows & Linux
IIUC this should happen automatically? The major problem with BBv1 was
that it assumed that the host OS was the same as the target OS. I hope
that BBv2 makes no such assumptions.
> Does that require some deep support from build system?
>>>>- mutilple hardware targets: MIPS, PowerPC, SH-4, ARM, StrongArm, IntelÂ®
>>>>XScaleâ¢ Microarchitecture, and x86
> Is that anyting more than an extra command line option?
Nope. architecture=x86, architecture=ppcbe are good examples.
What I think we need is something like this (modified gcc)
"$(CONFIG_COMMAND)" $(LANG) $(VARIANT) -ftemplate-depth-100
$(OPTIONS) -D$(DEFINES) -I"$(INCLUDES)" -c -o "$(<)" "$(>)"
Where an example of VARIANT is "-V3.3.5,gcc_ntox86_cpp" i.e.
"-V" + <gcc-version> + ",gcc_nto" + <architecture> + "_" + <stdlib>
gcc-version = 2.95.3 | 3.3.1 | 3.3.5
architecture = armbe | armle | mipsbe | mipsle | ppcbe | shle | x86
stdlib = cpp | gpp
CONFIG_COMMAND is normally "QCC" for C++ and "qcc" for C. However, this
presents a problem for Windoze because it is case insensitive. Hence the
LANG = "-lang-c++" | "-lang-c"
to make it universal.
> The only big problem seems to be using both gcc and intel as backend.
To repeat, forget about Intel.
> we've agreed to postpone that for later. So, I'd think the best idea now
> would be to inherit qcc.jam from gcc.jam, and then start testing it.
Go for it...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk