* [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-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
* 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
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