|
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