Boost logo

Boost-Build :

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2007-12-01 13:04:27


Hi Volodya,

On Dec 1, 2007 3:45 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
>
> I was doing some documentation, and it seems to me that
> architecture/instruction-set are confusingly named, and implemented.

I don't use boost.build for cross-compiling, so my opinion might be a
little biased.

> For start, most compilers distinguish between generating code for
> a given processor (which won't run on different processors, in general),
> and tuning code for a given processor. gcc.jam uses <instruction-set>
> to set -march, which is the hard processor selection. msvc.jam uses
> <instruction-set> for /flavor -- which is "soft" tuning selection.
> Should we have another <tune> option?

I think tune is a nice name, though maybe a little too short.
How about <cpu-tune>?

> Also, now 'architecture' is general family (x86, ia64, sparc), and
> 'instruction-set' is specific processor there. It does not seem to be
> that 'architecture' is right name here

I find it a good name. Though sometimes architecture might be
interpreted with respect to which OS it will run too. Not only the
CPU.

> -- after all, how the processor
> is implemented internally is surely changed radically, several time,
> during lifetime of x86.

I don't think it matters how a processor is implemented or
reimplemented to boost.build naming scheme.

> Would a better naming be:
>
> - cpu-family (for general family, keeping backward
> compatibility of some sort)
> - cpu (for exact cpu to target)
>
> Or maybe we should just use 'cpu' with subfeatures for exact cpu?
> Like
>
> cpu=x86-nocona
>
> ?

How about:

<architecture>x86
<cpu-tune>pentium4
<cpu>pentium3
?

Where <cpu> is the minimum required to run.
Does it mirror well to other architectures?

>
> - Volodya
>
> --
> Vladimir Prus
> http://vladimir_prus.blogspot.com
> Boost.Build V2: http://boost.org/boost-build2

Best regards,

-- 
Felipe Magno de Almeida

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