* Build process optimisation
@ 2016-04-06 0:55 Trevor Higgins
2016-04-06 1:05 ` [9front] " Nicolas Owens
2016-04-06 12:03 ` cinap_lenrek
0 siblings, 2 replies; 6+ messages in thread
From: Trevor Higgins @ 2016-04-06 0:55 UTC (permalink / raw)
To: 9front
I am building under Virtual box with u9fs fs served from linux.
I have encountered many small issues in getting everything setup and so
I have had to restart the build
process frequently.
The build process always rebuilds the libraries even though they have
not changed and do not require rebuilding. This make the whole build
process unduly painful.
I have tried binding /sys/sys/cmd/mklib over mksyslib but the mklib does
not handle a dependency where no targets needing rebuilding. Ie
libname(): don't know how to build.
Anyone got any advice on how I can restart the build without having to
spend 30minutes churning over all the libraries or how to change the
makefile to skip them if they are built?
cheers.
--
We need another plan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] Build process optimisation
2016-04-06 0:55 Build process optimisation Trevor Higgins
@ 2016-04-06 1:05 ` Nicolas Owens
2016-04-06 12:03 ` cinap_lenrek
1 sibling, 0 replies; 6+ messages in thread
From: Nicolas Owens @ 2016-04-06 1:05 UTC (permalink / raw)
To: 9front
have you tried using mk -e?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] Build process optimisation
2016-04-06 0:55 Build process optimisation Trevor Higgins
2016-04-06 1:05 ` [9front] " Nicolas Owens
@ 2016-04-06 12:03 ` cinap_lenrek
2016-04-06 23:26 ` Plan9
1 sibling, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2016-04-06 12:03 UTC (permalink / raw)
To: 9front
waiiit... 30 minutes churning over libraries? this is way too slow,
your vbox is crap, dont use it.
doing mk libs, which does mk clean in each lib before rebuilding gives me
30 *seconds* over remote fileserver... locally its more like 14 seconds
on my pentium d fileserver.
cd /sys/src; time mk libs
...
11.00u 10.39s 28.94r mk libs
and just mk (without mk clean in each lib) gives me 10 seconds:
time rc -c 'for(i in lib*){cd $i && mk && cd ..}'
...
1.07u 2.17s 10.29r rc -c for(i in lib*){cd $i && mk && cd ..}
if you just do "mk" in /sys/src, it does not clean the libraries.
if you do not want to touch the libraries, just do mk in /sys/src/cmd
or some other individual sub-directory if you know the dependencies
are fine already.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] Build process optimisation
2016-04-06 12:03 ` cinap_lenrek
@ 2016-04-06 23:26 ` Plan9
2016-04-06 23:35 ` sl
2016-04-06 23:37 ` cinap_lenrek
0 siblings, 2 replies; 6+ messages in thread
From: Plan9 @ 2016-04-06 23:26 UTC (permalink / raw)
To: 9front
I would love to ditch Vbox. Qemu is much slower.
I could change from using user mode networking but thats not the major
slow down.
I would love to have a box dedicated to P9 (may use my rpi one day) but
at present, work dictates I have something that I can do embedded
development with, so linux it is.
My main need to to compile for arm and mips which I have not found
anyway other than from within P9 OS. Ie plan9port and 9vx have issues
one way or another with plan9front.
Anyone got a better solution, please advise.
Re Build:
As I am cross compiling, making from /sys/src is ultimately necessary
and even building from lib cause libs to be rebuilt.
I have checked timestamps on Host vs P9 VM and it is not a time sync
issue.
Building libraries with <mksyslib always calls 'ar vu <targetlist>'
regardless of need to do so.
I assume this is done for a good reason otherwise the mkfile would use
mklib which does not do this.
Main build problems are after I do a 'hg pull' as there seems to always
be something that does not build (like btc for arm , presently).
Cheers.
On 2016-04-07 00:03, cinap_lenrek@felloff.net wrote:
> waiiit... 30 minutes churning over libraries? this is way too slow,
> your vbox is crap, dont use it.
>
> doing mk libs, which does mk clean in each lib before rebuilding gives
> me
> 30 *seconds* over remote fileserver... locally its more like 14 seconds
> on my pentium d fileserver.
>
> cd /sys/src; time mk libs
> ...
> 11.00u 10.39s 28.94r mk libs
>
> and just mk (without mk clean in each lib) gives me 10 seconds:
>
> time rc -c 'for(i in lib*){cd $i && mk && cd ..}'
> ...
> 1.07u 2.17s 10.29r rc -c for(i in lib*){cd $i && mk && cd ..}
>
> if you just do "mk" in /sys/src, it does not clean the libraries.
>
> if you do not want to touch the libraries, just do mk in /sys/src/cmd
> or some other individual sub-directory if you know the dependencies
> are fine already.
>
> --
> cinap
--
--
We need another plan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] Build process optimisation
2016-04-06 23:26 ` Plan9
@ 2016-04-06 23:35 ` sl
2016-04-06 23:37 ` cinap_lenrek
1 sibling, 0 replies; 6+ messages in thread
From: sl @ 2016-04-06 23:35 UTC (permalink / raw)
To: 9front
> I would love to ditch Vbox. Qemu is much slower.
You said you were running Linux, where qemu (kvm) is probably
fastest.
Does VMware still run on Linux?
sl
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] Build process optimisation
2016-04-06 23:26 ` Plan9
2016-04-06 23:35 ` sl
@ 2016-04-06 23:37 ` cinap_lenrek
1 sibling, 0 replies; 6+ messages in thread
From: cinap_lenrek @ 2016-04-06 23:37 UTC (permalink / raw)
To: 9front
i dont really understand what your problem is. it makes no sense to me.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-04-06 23:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-06 0:55 Build process optimisation Trevor Higgins
2016-04-06 1:05 ` [9front] " Nicolas Owens
2016-04-06 12:03 ` cinap_lenrek
2016-04-06 23:26 ` Plan9
2016-04-06 23:35 ` sl
2016-04-06 23:37 ` cinap_lenrek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).