Re: [Boost-build] V2/1.34: next steps

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...

>>>>qcc supports:
>>>>
>>>>- 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?

Nope.

>>>>- 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)

actions compile.c++
{
     "$(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>

Currently -

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 
need for

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.

> However, 
> 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...

Jim