Gentoo Archives: gentoo-portage-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] Re: running ebuild in src tree
Date: Thu, 12 Mar 2015 01:27:55
Message-Id: pan$6e3ee$4a4de8a4$7becebab$fb6cf384@cox.net
In Reply to: Re: [gentoo-portage-dev] running ebuild in src tree by Zac Medico
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

Replies

Subject Author
Re: [gentoo-portage-dev] Re: running ebuild in src tree Joakim Tjernlund <joakim.tjernlund@×××××××××.se>