[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ltib] XFree86 package
From: |
Stuart Hughes |
Subject: |
Re: [Ltib] XFree86 package |
Date: |
Thu, 16 Aug 2007 10:14:02 +0100 |
On Wed, 2007-08-15 at 12:54 -0400, Peter Barada wrote:
> On Wed, 2007-08-15 at 16:39 +0100, Stuart Hughes wrote:
>
> > I hope to do a complete re-merge update before the end of September, but
> > that depends a lot on how my other project progresses. If you're using
> > an ISO image from Freescale, you already have these updates. The reason
> > I haven't merged out is because I want to do some major re-structuring
> > before I do so and didn't want to confuse people with 2 big updates.
> > The purpose of the re-structure is to move all the BSP specific parts
> > (kernel spec files mostly) into the config/platform/<target> directory.
> > This would separate out the LTIB tool from the platform part completely.
> > The idea being that maintenance is easier and "writing a new BSP" is
> > simplified to just adding a new directory with a few files.
>
> I was going to ask if you also intend to have u-boot spec/patch files in
> the config platform directory as well, but as I was thinking about it,
> instead, can you generalize things so that the config/platform/<target>
> directory is searched first for spec/patch files
> before /opt/freescale/pkgs and dist/lfs-5.1?
>
> This would allow collecting *all* the changes necessary to support a new
> platform/BSP into the config/platform/<target> directory. It also would
> allow a BSP to supply not only brand new packages, but also patches and
> spec files for system packages. As an example, on a board I'm working
> with, it has a video chip that is little-endian with a processor that is
> big-endian. To complicate matters, its alpha verison has 3/3/3 pixels
> in a 16-bit word, soon to change to 5/5/5. This requires changess to
> microwindows to support this pixel layout as well as pixel access (has
> to be 32-bit access to modify just a 16-bit pixel, odd pixels in most
> significant short of a 32-bit word, even pixels in least significant
> short of a 32-bit word). Rather than having patch files that may affect
> other targets, my changes would be isolated to just my target.
>
Hi Peter,
The u-boot spec files (and any other board specific spec files) will be
moved to config/platform/<target>. Note that this directory is already
searched first when looking for spec files. Note also that if you need
to use a different version of a package, you can do this by putting an
entry in the pkg_map file in the config/platform/<target> directory
I don't intend to put any sources/patches into config/platform/<target>.
The reason is that I want to keep the references to the data and the
data itself separate. This is because:
* Patches are derived from changes and sources themselves and so I don't
want to place derived data under SCM management.
* By forcing patches into a common area (http://bitshrine.orf/gpp
/opt/ltib/pkgs ) it means that every patch must be uniquely named.
This means that patch xyz can always relied upon to have the same
content in the same way that <pkg-version>.tar.gz can be.
Regards, Stuart
- [Ltib] XFree86 package, Ken Gilmer, 2007/08/14
- Re: [Ltib] XFree86 package, Stuart Hughes, 2007/08/15
- Re: [Ltib] XFree86 package, Ken Gilmer, 2007/08/15
- Re: [Ltib] XFree86 package, Stuart Hughes, 2007/08/15
- Re: [Ltib] XFree86 package, Peter Barada, 2007/08/15
- Re: [Ltib] XFree86 package,
Stuart Hughes <=
- [Ltib] LTIB and Eclipse, Ken Gilmer, 2007/08/16
- Message not available
- Re: [Ltib] LTIB and Eclipse, Ken Gilmer, 2007/08/16
- Re: [Ltib] LTIB and Eclipse, John Weber, 2007/08/16
- Re: [Ltib] LTIB and Eclipse, Stuart Hughes, 2007/08/17