Josef Holzmayr writes:
read the thread for context...
> See 3) for one.. at least for me, the BSP I start off evolves into the
> thing I want to have, including the code.
>
> FWIW, this is the easiest way to view a ptxdist project: its basically
> an application including everything you need
Howdy!
Am 21.02.2012 17:08, schrieb Jerry Kirk:
Josef Holzmayr writes:
Any advice would be great to try and avoid painful restructures.
~/ptxdist/releases Here I keep the built ptxdist releases
/toolchains The OSELAS.Toolchain things are here
/sources I downl
Josef Holzmayr writes:
> > Any advice would be great to try and avoid painful restructures.
>
> ~/ptxdist/releasesHere I keep the built ptxdist releases
> /toolchains The OSELAS.Toolchain things are here
> /sourcesI download all sources to here
>
Hei Jerry,
Am 2012-02-20 23:21, schrieb Jerry Kirk:
> Our development will run the full breadth including new drivers,
> patches to existing drivers, applications, etc.
Speaking of VCS: we put each subproject in separate repositories and
build ordinary ptxdist packages for it. So for application
Howdy!
Am 20.02.2012 23:21, schrieb Jerry Kirk:
I've been reviewing the "practical project workspace" outlined in O'Reilly's
Building Embedded Linux Systems book.
Yes, Karims suggestions don't align too well with ptxdist.
We're using some sort of cloud based DVCS system for sourc code
contro
I'm looking for some advice on how to structure the source code directories of
our new embedded linux project that will rely on PTXDist. Our development will
run the full breadth including new drivers, patches to existing drivers,
applications, etc.
I've been reviewing the "practical project wo
