* [ptxdist] Advice on Directory Structure
@ 2012-02-20 22:21 Jerry Kirk
2012-02-21 8:58 ` Josef Holzmayr
2012-02-21 9:39 ` Alexander Dahl
0 siblings, 2 replies; 6+ messages in thread
From: Jerry Kirk @ 2012-02-20 22:21 UTC (permalink / raw)
To: ptxdist
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 workspace" outlined in O'Reilly's
Building Embedded Linux Systems book. It's a fair start but not as detailed as
I had hoped. We're using some sort of cloud based DVCS system for sourc code
controla s well.
Any advice would be great to try and avoid painful restructures.
--
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ptxdist] Advice on Directory Structure
2012-02-20 22:21 [ptxdist] Advice on Directory Structure Jerry Kirk
@ 2012-02-21 8:58 ` Josef Holzmayr
2012-02-21 16:08 ` Jerry Kirk
2012-02-21 9:39 ` Alexander Dahl
1 sibling, 1 reply; 6+ messages in thread
From: Josef Holzmayr @ 2012-02-21 8:58 UTC (permalink / raw)
To: ptxdist
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
> controla s well.
See below for my personal way of integrating all this:
> 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 download all sources to here
(ptxdist setup -> source directories)
/projects/a Every project the gets a symlink to the
/b ptxdist binary it uses, and done.
/c These directories should go into your SCM.
For the layout of any project directory, you can check out the mini2440
BSP
(http://www.pengutronix.de/oselas/bsp/pengutronix/mini2440_bsp_en.html),
as it includes a working structure fitting for ptxdist including
examples for the difference board/project/etc.
Hope that helps a bit, or just hop into #ptxdist on freenode for
discussion :)
Greetz
_____________________________________________________________
Josef Holzmayr
Dipl-Ing. (FH)
Entwicklung Embedded Devices / Software
Tel.: +49 8444 9204-48>
Fax: +49 8444 9204-50
holzmayr@rsi-elektrotechnik.de
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ptxdist] Advice on Directory Structure
2012-02-20 22:21 [ptxdist] Advice on Directory Structure Jerry Kirk
2012-02-21 8:58 ` Josef Holzmayr
@ 2012-02-21 9:39 ` Alexander Dahl
1 sibling, 0 replies; 6+ messages in thread
From: Alexander Dahl @ 2012-02-21 9:39 UTC (permalink / raw)
To: ptxdist
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 foo we make
our own rules/foo.in and rules/foo.make and foo has its own repository
besides the repo for the BSP itself. This allows building applications
(or libraries, drivers, …) to be build for other platforms without
ptxdist.
(This makes the development process a little difficult if you want to
hack on the sources extracted by ptxdist. We have our own scripts for
checking out from git, but this breaks with ipkg version numbering, not
that perfect atm. ;) )
We had applications, libraries and some other things in one subversion
repository before we used one git repo for each subproject and that was
exactly the pain in the ass you want to avoid. ;-)
Greets
Alex
--
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 ***
--
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ptxdist] Advice on Directory Structure
2012-02-21 8:58 ` Josef Holzmayr
@ 2012-02-21 16:08 ` Jerry Kirk
2012-02-21 16:36 ` Josef Holzmayr
0 siblings, 1 reply; 6+ messages in thread
From: Jerry Kirk @ 2012-02-21 16:08 UTC (permalink / raw)
To: ptxdist
Josef Holzmayr <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 download all sources to here
> (ptxdist setup -> source directories)
> /projects/a Every project the gets a symlink to the
> /b ptxdist binary it uses, and done.
> /c These directories should go into your SCM.
>
> For the layout of any project directory, you can check out the mini2440
> BSP
> (http://www.pengutronix.de/oselas/bsp/pengutronix/mini2440_bsp_en.html),
> as it includes a working structure fitting for ptxdist including
> examples for the difference board/project/etc.
Josef, thanks for your advice just a few followup questions (fgr anyone)
1. Do you still install the cross compilers in /OPT or do you try to include
them local to the project? I'm assuming you might wind up with multiple
toolchains.
2. In your example of projects/[abc] are you starting from a known BSP and
then customizing the config files, adding patches, etc. Is a Project really a
build image for the embedded device or just an application?
3. Do you keep the application code seperate in structure (and in code control
repository) and just sym-link the directory to the "local_src" direcetory?
4. In general, how much do you try to seperate your code from the starting BSP?
--
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ptxdist] Advice on Directory Structure
2012-02-21 16:08 ` Jerry Kirk
@ 2012-02-21 16:36 ` Josef Holzmayr
2012-02-21 17:58 ` Jerry Kirk
0 siblings, 1 reply; 6+ messages in thread
From: Josef Holzmayr @ 2012-02-21 16:36 UTC (permalink / raw)
To: ptxdist
Howdy!
Am 21.02.2012 17:08, schrieb Jerry Kirk:
> Josef Holzmayr<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 download all sources to here
>> (ptxdist setup -> source directories)
>> /projects/a Every project the gets a symlink to the
>> /b ptxdist binary it uses, and done.
>> /c These directories should go into your SCM.
>>
>> For the layout of any project directory, you can check out the mini2440
>> BSP
>> (http://www.pengutronix.de/oselas/bsp/pengutronix/mini2440_bsp_en.html),
>> as it includes a working structure fitting for ptxdist including
>> examples for the difference board/project/etc.
>
> Josef, thanks for your advice just a few followup questions (fgr anyone)
>
> 1. Do you still install the cross compilers in /OPT or do you try to include
> them local to the project? I'm assuming you might wind up with multiple
> toolchains.
Yes, I install them there. The toolchains are behaving well and sticking
to their own directories, so no problems. I personally see nothing bad
in using /opt for that. (think data deduplication when you have multiple
developers on the machine)
> 2. In your example of projects/[abc] are you starting from a known BSP and
> then customizing the config files, adding patches, etc. Is a Project really a
> build image for the embedded device or just an application?
Yes, for me a project is the complete BSP including all sources,
patches, applications etc. i need to build the final image.
> 3. Do you keep the application code seperate in structure (and in code control
> repository) and just sym-link the directory to the "local_src" direcetory?
I haven't had the need to seperate the applications out of the project,
because my apps(*sic*) are usually highly project specific. Hence, I
view the project altogether as the thing i keep in SCM.
> 4. In general, how much do you try to seperate your code from the starting BSP?
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 to run it. It can in turn
contain several platforms to build for different targets, and the same
holds true for software configurations.
Might of course be I use it all in a way not intended, but it works well
for me :)
Greetz
_____________________________________________________________
Josef Holzmayr
Dipl-Ing. (FH)
Entwicklung Embedded Devices / Software
Tel.: +49 8444 9204-48>
Fax: +49 8444 9204-50
holzmayr@rsi-elektrotechnik.de
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ptxdist] Advice on Directory Structure
2012-02-21 16:36 ` Josef Holzmayr
@ 2012-02-21 17:58 ` Jerry Kirk
0 siblings, 0 replies; 6+ messages in thread
From: Jerry Kirk @ 2012-02-21 17:58 UTC (permalink / raw)
To: ptxdist
Josef Holzmayr <holzmayr@...> writes:
<! SNIP !> 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 to run it. It can in turn
> contain several platforms to build for different targets, and the same
> holds true for software configurations.
>
> Might of course be I use it all in a way not intended, but it works well
> for me :)
Thanks again Josef that really clears some tings up for me. One last (for now)
question. I am planning on one piece of hardware that supports two products.
Each p[roduct will share all the low level Linux stuff but will have two
different top-level applications.
Is that type of organization best served by two PTXDist software config files
and only one platform file? It seems that splitting them into
separate "~/projects/[ab]" would cause a lot of code/patch/config duplication.
--
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-21 17:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-20 22:21 [ptxdist] Advice on Directory Structure Jerry Kirk
2012-02-21 8:58 ` Josef Holzmayr
2012-02-21 16:08 ` Jerry Kirk
2012-02-21 16:36 ` Josef Holzmayr
2012-02-21 17:58 ` Jerry Kirk
2012-02-21 9:39 ` Alexander Dahl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox