All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: Jamie Lenehan <lenehan@twibble.org>
Cc: openembedded-devel@openembedded.org
Subject: Re: site/* - using common files for site information
Date: Fri, 25 Aug 2006 09:40:56 +0100	[thread overview]
Message-ID: <1156495256.5554.16.camel@localhost.localdomain> (raw)
In-Reply-To: <20060825082210.GA18599@twibble.org>

On Fri, 2006-08-25 at 18:22 +1000, Jamie Lenehan wrote:
> On Fri, Aug 25, 2006 at 09:08:09AM +0100, Richard Purdie wrote:
> I changed my mind about a dozen times on this, so seeing what someone
> else thinks would be good. 

I'll try and take a look at the patches this weekend. I can't promise
but I will try :).

> > review the patches. The name info.bbclass is perhaps too generic though
> > - could you call it something like autotools-info.bbclass?
> 
> The reason I called it info.bbclass is because it's not actually
> related to autotools. What it does is provide information about a
> target - endianess, 32/64 bit, which libc it's using, what alias
> exists for it in a general sort of way.
> 
> The autotools.bbclass then makes use of this to decided which site
> files to use.

You can argue that both ways. Ultimately, those files are generally used
by configure which implies autotools but other packages also use them to
provide supplementary info, just to confuse the issue :). I like the
idea of some functions like get_info_endianess_select (although your
example doesn't quite match with get_info_choice_endianess) and it would
be good to abstract direct access to the site files.

I still feel info is too generic as we have 101 different forms of info
around and we need to find a better more descriptive name.
config-info.bclass? site-config.bbclass? Calling it autotools-info
doesn't mean none autotooled packages can't use it btw!

> I also made use of the info.bbclass to provide the endiness
> information to recipes that were currently manaully looking in the
> site file to determine this (since the way they currently work breaks
> with the site file.)

Just throwing ideas around, rather than create a function for each
option like endiness, why not have a variable which contains the
endiness set by the class and use base_conditional to get the value you
want? This might make things a little more flexiable?

Cheers,

Richard






  reply	other threads:[~2006-08-25  8:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060817105325.GA2172@twibble.org>
     [not found] ` <20060817153312.GA23152@twibble.org>
2006-08-25  5:33   ` site/* - using common files for site information Jamie Lenehan
2006-08-25  8:08     ` Richard Purdie
2006-08-25  8:22       ` Jamie Lenehan
2006-08-25  8:40         ` Richard Purdie [this message]
2006-08-25  9:34           ` Jamie Lenehan
2006-08-25  9:57           ` Michael 'Mickey' Lauer
2006-08-28  0:05           ` Jamie Lenehan

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=1156495256.5554.16.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=lenehan@twibble.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.