[oe] introducing a new architecture/machine; policy ? (and a question)

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Wed Jun 23 11:16:42 UTC 2010


2010/6/23 Koen Kooi <k.kooi at student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23-06-10 12:07, Philip Balister wrote:
>> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
>>> On Wed, 23 Jun 2010 11:54:21 +0200
>>> Frans Meulenbroeks<fransmeulenbroeks at gmail.com>  wrote:
>>>
>>>> 2010/6/23 Graeme Gregory<dp at xora.org.uk>:
>>>>>>>> Also I don't feel empowered to make changes in distribution
>>>>>>>> specific files.
>>>>>
>>>>> Why not, chances are Angstrom maintainers would be quite happy for
>>>>> you to patch angstrom*.conf if you ask us.
>>>>>
>>>>> Graeme
>>>>
>>>> distribution != angstrom
>>>> There are more distributions out there.
>>
>> Right now, toolchain selection is done in distro files not machine
>> files. I agree this is not the clearest approach, however adding the
>> toolchain selection to the machine files may have unexpected side effects.
>
> Think of multimachine builds. What happens when someone else adds
> *another* nios2 based machine with different toolchain versions, how do
> I know which toolchain avahi_1.0_nios2.ipk was compiled with

If toolchain is interesting to know in ipk's it should be part of the name.
And note that I am really in favour of an architecture specific
solution, not a machine one.
That is why I used an include file to contain the pinnings.

And actually the situation with nios2 is much much worse.
As it is a soft-core people can come up with all kind of variants.
(e.g. with/without fp). Actually nios2 adds pragma's to gcc to select
which instructions are there and which not.
Not sure whether the latter is a good idea as it is one of the things
that fail moving to a newer gcc.

The good news is that most of the variants used have different
peripherals, but seem to stick to just a few cpu cores.
(nios2 is used as a generic name for the SoC as well as the core,
doesn't help to separate things either).

Frans




More information about the Openembedded-devel mailing list