9front - general discussion about 9front
 help / color / mirror / Atom feed
* 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).