1 |
Zac Medico posted on Wed, 11 Mar 2015 12:03:10 -0700 as excerpted: |
2 |
|
3 |
> On 03/11/2015 11:56 AM, Joakim Tjernlund wrote: |
4 |
>> On Wed, 2015-03-11 at 11:34 -0700, Zac Medico wrote: |
5 |
>>> On 03/11/2015 09:03 AM, Joakim Tjernlund wrote: |
6 |
>>>> When developing code it would be really nice if one could run your |
7 |
>>>> ebuild on that src tree as is(no fetch, unpack etc.) |
8 |
>>> |
9 |
>>> The existing convention is to create an ebuild with version 9999 and |
10 |
>>> use one of the live vcs eclasses such as git-r3 to pull the live |
11 |
>>> sources in the src_unpack function. In a future EAPI, we plan to add |
12 |
>>> some features related to this [1]. |
13 |
>> |
14 |
>> I think you misunderstand, [1] is not what I want to do(I think): |
15 |
>> |
16 |
>> Got my src working copy and made a few modds, not commitet yet. |
17 |
>> Now I just want build/test etc. before committing and to do that I just |
18 |
>> run mytree/overlay/dev-util/myapp/myapp.ebuild compile and voila, my |
19 |
>> code is built which I already have in mytree. |
20 |
> |
21 |
> Well, you can create a -9999 ebuild that copies your sources from |
22 |
> $directory to $WORKDIR. Maybe use an environment to configure whether it |
23 |
> pulls from a local directory or a vcs repository. |
24 |
|
25 |
@ Joakim T: |
26 |
|
27 |
FWIW, a commonly recommended user-level portage optimization is to point |
28 |
$PORTAGE_TMPDIR at a tmpfs mount. As long as you have sufficient memory, |
29 |
that lets all building take place in the tmpfs and thus in memory, |
30 |
eliminating many read-accesses and most/all write accesses to permanent |
31 |
storage during the build and (fake-)install phases. |
32 |
|
33 |
In addition to speeding up emerge itself, this reduces build-time I/O, |
34 |
which often becomes the bottleneck on which other processes may be |
35 |
waiting as well, thus allowing other processes more efficient access to |
36 |
permanent storage while emerge is ongoing. Between this and setting |
37 |
PORTAGE_NICENESS=20, emerge is /much/ better behaved during builds, |
38 |
interrupting other processes much less and thus letting you carry on with |
39 |
other things while emerge is doing its thing, with far less interruption. |
40 |
=:^) |
41 |
|
42 |
For instance, here I have /tmp as a tmpfs mount (with /var/tmp being a |
43 |
bind-mount of the same tmpfs), and in make.conf, have the line: |
44 |
|
45 |
PORTAGE_TMPDIR=/tmp |
46 |
|
47 |
Emerge then creates /tmp/portage, and within it, creates the usual cat/ |
48 |
pkg/ build trees, etc, as it emerges various packages. |
49 |
|
50 |
|
51 |
Obviously, your sources in permanent storage are going to be cache-copied |
52 |
into memory as you do the build anyway, and pointing PORTAGE_TMPDIR at |
53 |
tmpfs then becomes a copy to (tmpfs) memory only. While that doesn't |
54 |
technically eliminate the copies (since the read into tmpfs will cache |
55 |
and you'll have the tmpfs copy as well), it DOES mean most of the work |
56 |
beyond the initial read into memory will be memory-only, so you DO |
57 |
eliminate the permanent-storage copies. |
58 |
|
59 |
Is that sufficiently close to what you were looking to do? Beyond that, |
60 |
as Zac suggests, just have the ebuild grab the sources from wherever you |
61 |
put them as your src_unpack, as at that point it'll be a copy to tmpfs, |
62 |
and thus take essentially the same time (or even less since it'll avoid |
63 |
the build-time writes to permanent storage) as doing the in-place build |
64 |
directly. Plus, creating a tmpfs mount if necessary, and setting |
65 |
PORTAGE_TMPDIR, is easy, and you'll dramatically speed-up normal builds |
66 |
as well. =:^) |
67 |
|
68 |
-- |
69 |
Duncan - List replies preferred. No HTML msgs. |
70 |
"Every nonfree program has a lord, a master -- |
71 |
and if you use the program, he is your master." Richard Stallman |