1 |
Hi Sergey, |
2 |
|
3 |
On Mon, Jan 23, 2012 at 11:35:46AM +0400, Sergey Mironov wrote: |
4 |
> Hi. Model |
5 |
> |
6 |
> > /usr/ |
7 |
> > arm-none-linux-gnueabi/ -> projectA/ |
8 |
> > arm-none-linux-gnueabi.orig/ |
9 |
> > projectA/ |
10 |
> > projectB/ |
11 |
> > ... |
12 |
> > projectN/ |
13 |
> > |
14 |
> > with arm-none-linux-gnueabi.orig/ being the original contents after |
15 |
> > crossdev built the toolchain. As I create projects, I would 'cp -a |
16 |
> > arm....orig/* projectN/' |
17 |
> > |
18 |
> |
19 |
> there is one drawback here - compiler version. Looks like gentoo |
20 |
> stores libc files in /usr/lib/gcc/arm-projectA-linux-gnueabi/1.2.3 |
21 |
> so it will probably break something if you use different gcc for your projects. |
22 |
|
23 |
Yes, I remember falling into that trap before, with libgcc.a, etc. The |
24 |
above layout assumed a single, static cross-compiler. Updates to the |
25 |
cross-compiler would then necessitate rebuilding all the projects. |
26 |
|
27 |
> > How do folks out there handle multiple projects with the same toolchain? |
28 |
> > I'm thinking, since crossdev worked so well, to just build a |
29 |
> > 'arm-projectA-linux-gnueabi' and then 'arm-projectB-linux-gnueabi' to |
30 |
> > keep the roots separate. |
31 |
> > What do you guys use? |
32 |
> |
33 |
> I use 'arm-projectA-linux-gnueabi' approach. It works, but still not |
34 |
> ideal - For example, I can't just copy the whole folder to another |
35 |
> gentoo machine and continue use emerge-projectA there. |
36 |
|
37 |
I don't anticipate much need to migrate /usr/cross-compiler to other |
38 |
machines. As long as I keep the ebuilds for the cross-compiler |
39 |
components, crossdev, and the packages, I should be able to rebuild any |
40 |
given project from scratch. |
41 |
|
42 |
I should probably set up a separate overlay per project to accomplish |
43 |
that. |
44 |
|
45 |
thx, |
46 |
|
47 |
Jason. |