Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: introducing a new architecture/machine; policy ? (and a question)
Date: Wed, 23 Jun 2010 15:20:53 -0700	[thread overview]
Message-ID: <20100623222053.GC6653@gmail.com> (raw)
In-Reply-To: <AANLkTimou2cL3hKrb7Yrqp1h4MH-AkWVVXFN2MKkv5ic@mail.gmail.com>

On (23/06/10 21:55), Frans Meulenbroeks wrote:
> 2010/6/23 Khem Raj <raj.khem@gmail.com>:
> > On (23/06/10 13:16), Frans Meulenbroeks wrote:
> >> 2010/6/23 Koen Kooi <k.kooi@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@gmail.com>  wrote:
> >> >>>
> >> >>>> 2010/6/23 Graeme Gregory<dp@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).
> >
> > not new. Other arches have similar variants already in OE
> 
> I know, but at least in those architectures if you have a board the
> situation is static.
> In fpga's capable of having a nios2 machine, it is still possible to
> load different configurations.

how many ? if they are managable you can still use the existing relation of
machine to them but if you really want to make it configurable then you
might think of writing a class which would define these configurations
somehow may be you can denote various configs through some bitbake var
then.



  reply	other threads:[~2010-06-23 22:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-20  9:58 introducing a new architecture/machine; policy ? (and a question) Frans Meulenbroeks
2010-06-20 10:10 ` Frans Meulenbroeks
2010-06-20 12:35 ` Koen Kooi
2010-06-20 15:38   ` Frans Meulenbroeks
2010-06-23  8:53     ` Frans Meulenbroeks
2010-06-23  9:24       ` Koen Kooi
2010-06-23  9:36         ` Graeme Gregory
2010-06-23  9:54           ` Frans Meulenbroeks
2010-06-23 10:03             ` Graeme Gregory
2010-06-23 10:07               ` Philip Balister
2010-06-23 10:32                 ` Koen Kooi
2010-06-23 11:16                   ` Frans Meulenbroeks
2010-06-23 17:19                     ` Khem Raj
2010-06-23 19:55                       ` Frans Meulenbroeks
2010-06-23 22:20                         ` Khem Raj [this message]
2010-06-23 17:15             ` Khem Raj
2010-06-23 17:18               ` Tom Rini
2010-06-23 10:09         ` Frans Meulenbroeks
2010-06-23 10:30           ` Koen Kooi
2010-06-23 17:23           ` Khem Raj
2010-06-23 20:04             ` Frans Meulenbroeks
2010-06-23 21:55               ` Adrian Alonso
2010-06-23 22:16                 ` Khem Raj
2010-06-23 22:26               ` Khem Raj
2010-06-24  9:27               ` Koen Kooi
2010-06-24 11:23                 ` Frans Meulenbroeks
2010-06-24 15:10                   ` Khem Raj
2010-06-20 22:59 ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100623222053.GC6653@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox