Re: introducing a new architecture/machine; policy ? (and a question)

[Koen Kooi <k.kooi@student.utwente.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-06-10 12:09, Frans Meulenbroeks wrote:
> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 23-06-10 10:53, Frans Meulenbroeks wrote:
>>> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>>>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>>>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>>>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>>>>>> Is there a policy on on the process how to do this.
>>>>>
>>>>> Have a look at the nios2 patches Leon sent last december, they were
>>>>> reviewed on this list, but not committed.
>>>>
>>>> Koen, thanks for reminding me the look at the review comments.
>>>>
>>>> I'm well aware of the work of Leon and Walter (and they are well aware
>>>> of my work).
>>>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
>>>> changes I have is for an mmu core.
>>>>
>>>> Triggered by Koens reminder I revisited the review comments. Actually
>>>> none but one are applicable for me.
>>>> The one that is applicable is the one about pinning versions in
>>>> machine descriptions.
>>>> I have also done that, as there are simply no other versions of
>>>> binutils and gcc that can be used by this hardware.
>>>> Also I don't feel empowered to make changes in distribution specific files.
>>>>
>>>> The only alternative way that I can think of is doing something like:
>>>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
>>>> No idea if that overrules the distro settings or not, but I can give
>>>> it a try later today.
>>>
>>> Well, tried it and apparently a distro pin has priority over a
>>> DEFAULT_PREFERENCE_nios2 in the recipe.
>>> Guess I'll have to do the pinning the the machine description as
>>> described above.
>>
>> NO! Machines *never* pin versions, that's what distros and to a lesser
>> extent recipes are for.
> 
> The issue is that I have no way to specify which versions of a
> toolchain that are supported (and to enforce that only a supported
> version works).

You have no way to pin versions based on arch? Angstrom does that just
fine for blackfin, avr32 and armv4:

# Blackfin has its on gcc
ANGSTROM_GCC_VERSION_bfin           = "4.1.2"

#avr32 only has support for gcc 4.2.2
ANGSTROM_GCC_VERSION_avr32      ?= "4.2.2"

#armv4 needs at least gcc 4.4.2 for eabi
ANGSTROM_GCC_VERSION_armv4              ?= "4.4.2"

#Everybody else can just use this:
ANGSTROM_GCC_VERSION                     ?= "4.3.3"

PREFERRED_VERSION_gcc                    ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross              ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross-sdk          ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross-initial      ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross-intermediate ?= "${ANGSTROM_GCC_VERSION}"

So what's stopping you from creating a patch that does

+ANGSTROM_GCC_VERSION_nios2-mmu = "4.1.2"

And similar for binutils? For other distros you can use sane-toolchain
or something.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMIeJUMkyGM64RGpERAs9AAJ4smKJ3ErSKzGa5ge5AJecDNjukqACaA/t/
ljn0G+lPaOSpjcI+l8B6LaA=
=vlrX
-----END PGP SIGNATURE-----