Gentoo Archives: gentoo-portage-dev

From: Alec Warner <antarus@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Re: running ebuild in src tree
Date: Sun, 15 Mar 2015 00:52:40
Message-Id: CAAr7Pr_gcCbWSNCB+JAQpqCbmcYGzxzeGhc8+j7Fy6mKMz3niw@mail.gmail.com
In Reply to: Re: [gentoo-portage-dev] Re: running ebuild in src tree by Joakim Tjernlund
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