1 |
On Thu, Mar 12, 2015 at 10:26 AM, Joakim Tjernlund < |
2 |
joakim.tjernlund@×××××××××.se> wrote: |
3 |
|
4 |
> On Thu, 2015-03-12 at 01:27 +0000, Duncan wrote: |
5 |
> > Zac Medico posted on Wed, 11 Mar 2015 12:03:10 -0700 as excerpted: |
6 |
> > |
7 |
> > > On 03/11/2015 11:56 AM, Joakim Tjernlund wrote: |
8 |
> > > > On Wed, 2015-03-11 at 11:34 -0700, Zac Medico wrote: |
9 |
> > > > > On 03/11/2015 09:03 AM, Joakim Tjernlund wrote: |
10 |
> > > > > > When developing code it would be really nice if one could run |
11 |
> your ebuild on that src tree as is(no |
12 |
> > > > > > fetch, unpack etc.) |
13 |
> > > > > |
14 |
> > > > > The existing convention is to create an ebuild with version 9999 |
15 |
> and use one of the live vcs eclasses |
16 |
> > > > > such as git-r3 to pull the live sources in the src_unpack |
17 |
> function. In a future EAPI, we plan to add |
18 |
> > > > > some features related to this [1]. |
19 |
> > > > |
20 |
> > > > I think you misunderstand, [1] is not what I want to do(I think): |
21 |
> > > > |
22 |
> > > > Got my src working copy and made a few modds, not commitet yet. Now |
23 |
> I just want build/test etc. before |
24 |
> > > > committing and to do that I just run |
25 |
> mytree/overlay/dev-util/myapp/myapp.ebuild compile and voila, my |
26 |
> > > > code is built which I already have in mytree. |
27 |
> > > |
28 |
> > > Well, you can create a -9999 ebuild that copies your sources from |
29 |
> $directory to $WORKDIR. Maybe use an |
30 |
> > > environment to configure whether it pulls from a local directory or a |
31 |
> vcs repository. |
32 |
> > |
33 |
> > @ Joakim T: |
34 |
> > |
35 |
> > FWIW, a commonly recommended user-level portage optimization is to point |
36 |
> > $PORTAGE_TMPDIR at a tmpfs mount. As long as you have sufficient memory, |
37 |
> > that lets all building take place in the tmpfs and thus in memory, |
38 |
> eliminating many read-accesses and |
39 |
> > most/all write accesses to permanent storage during the build and |
40 |
> (fake-)install phases. |
41 |
> > |
42 |
> > In addition to speeding up emerge itself, this reduces build-time I/O, |
43 |
> which often becomes the bottleneck |
44 |
> > on which other processes may be waiting as well, thus allowing other |
45 |
> processes more efficient access to |
46 |
> > permanent storage while emerge is ongoing. Between this and setting |
47 |
> PORTAGE_NICENESS=20, emerge is /much/ |
48 |
> > better behaved during builds, interrupting other processes much less |
49 |
> and thus letting you carry on with |
50 |
> > other things while emerge is doing its thing, with far less interruption. |
51 |
> > =:^) |
52 |
> > |
53 |
> > For instance, here I have /tmp as a tmpfs mount (with /var/tmp being a |
54 |
> bind-mount of the same tmpfs), and |
55 |
> > in make.conf, have the line: |
56 |
> > |
57 |
> > PORTAGE_TMPDIR=/tmp |
58 |
> > |
59 |
> > Emerge then creates /tmp/portage, and within it, creates the usual cat/ |
60 |
> pkg/ build trees, etc, as it |
61 |
> > emerges various packages. |
62 |
> > |
63 |
> > |
64 |
> > Obviously, your sources in permanent storage are going to be cache-copied |
65 |
> > into memory as you do the build anyway, and pointing PORTAGE_TMPDIR at |
66 |
> tmpfs then becomes a copy to |
67 |
> > (tmpfs) memory only. While that doesn't technically eliminate the |
68 |
> copies (since the read into tmpfs will |
69 |
> > cache and you'll have the tmpfs copy as well), it DOES mean most of the |
70 |
> work beyond the initial read into |
71 |
> > memory will be memory-only, so you DO eliminate the permanent-storage |
72 |
> copies. |
73 |
> > |
74 |
> > Is that sufficiently close to what you were looking to do? Beyond that, |
75 |
> > as Zac suggests, just have the ebuild grab the sources from wherever you |
76 |
> > put them as your src_unpack, as at that point it'll be a copy to tmpfs, |
77 |
> and thus take essentially the same |
78 |
> > time (or even less since it'll avoid the build-time writes to permanent |
79 |
> storage) as doing the in-place |
80 |
> > build directly. Plus, creating a tmpfs mount if necessary, and |
81 |
> setting PORTAGE_TMPDIR, is easy, and |
82 |
> > you'll dramatically speed-up normal builds as well. =:^) |
83 |
> > |
84 |
> |
85 |
> No, there can be no copy of sources for what I want. It just gets in the |
86 |
> way having to do that. |
87 |
> Hacks like this seems to work: |
88 |
> |
89 |
> |
90 |
I wouldn't really call it a hack either, but whichever ;) |
91 |
|
92 |
|
93 |
> post_src_compile() { |
94 |
> # make it compile every time |
95 |
> rm -f ${PORTAGE_BUILDDIR}/.compiled |
96 |
> } |
97 |
> |
98 |
> post_src_install() { |
99 |
> # make it install every time |
100 |
> rm -f ${PORTAGE_BUILDDIR}/.installed |
101 |
> } |
102 |
> |
103 |
> #hmm, doesn't seem to be an post_package function |
104 |
> #post_package() { |
105 |
> # rm -f ${PORTAGE_BUILDDIR}/.packaged |
106 |
> #} |
107 |
> |
108 |
> src_unpack() { |
109 |
> #dir need to exist |
110 |
> mkdir -p ${S} || die |
111 |
> } |
112 |
> src_compile() { |
113 |
> EBUILDDIR=$(dirname ${FILESDIR}) |
114 |
> MYTRUNK=${EBUILDDIR}/../../.. |
115 |
> # add sandbox exceptions |
116 |
> addwrite ${MYTRUNK} |
117 |
> |
118 |
> cd ${MYTRUNK} || die |
119 |
> cd "${PN}" |
120 |
> ..... |
121 |
> } |
122 |
> |
123 |
> I'm a bit curious what sort of workflow you are trying to achieve here is. |
124 |
Which build artifacts are you looking for; the actual built binaries or the |
125 |
built package that is merged into the livefs? |
126 |
|
127 |
If the artifacts are packages, then I think this approach makes some |
128 |
sense...but otherwise I'd just go into trunk and run the build process |
129 |
(what does the ebuild gain you here?) |
130 |
|
131 |
-A |