Contributed by weerd on from the render-the-fine-manpage dept.
On saturday, Ingo Schwarze (schwarze@) deleted groff(1) from the OpenBSD source tree. This is the culmination of a lot of work by Ingo but also Kristaps Dzonsons and Joerg Sonnenberger who are responsible for the new mandoc(1).
A lot of work has gone into mandoc recently. Those of you following the source-changes@ list have probably noticed the huge amount of work Ingo put in: 373 commits in 2010 alone, most of which were either directly related to mandoc or fixing bugs in manpages that did not show with groff. You may also remember our article on m2k10 about the mini hackathon on mandoc in May last year.
Ingo's log message hardly does justice to all the work that was done in the last two years and four months (Kristaps made his first commit to mdocml.bsd.lv in November 2008):
Replaced by mandoc(1) for base and xenocara purposes, and comes with 4.9 ports. ok deraadt@
Ingo will presenting a talk on mandoc at BSDCan 2011. If you have the chance, do go and see it!
The removal of groff means that src/ is now free of C++ code. Groff was also one of the slowest parts in a full build (and its replacement is much faster in rendering manpages). All in all, mandoc is a very nice improvement so a big thank you goes to Ingo, Kristaps and Joerg for their work.
(Comments are closed)
By Adam P (adamrt) fakeempire@gmail.com on
By phessler (phessler) spambox@theapt.org on http://theapt.org
Comments
By Paul 'WEiRD' de Weerd (weerd) on http://www.weirdnet.nl/openbsd/
Yes, sorry - I meant in src/
By phessler (phessler) spambox@theapt.org on http://theapt.org
Comments
By Amit Kulkarni (amitkulz) on http://forestlaw.blogspot.com
One more thing holding back fast compiles is the configure scripts, which just can't be made to do it in parallel.
Comments
By Janne Johansson (jj) on http://www.inet6.se
>
> One more thing holding back fast compiles is the configure scripts, which just can't be made to do it in parallel.
No, but there are things to be made for it also, like arla and/or heimdal-krb5 building against a once-generated configure run (at least partly), and ports that come with infrastructure/db/config.site which holds a bunch of premade answers to commmon stuff configure scripts look for.
Comments
By Marc Espie (espie) espie@nerim.net on
> >
> > One more thing holding back fast compiles is the configure scripts, which just can't be made to do it in parallel.
>
> No, but there are things to be made for it also, like arla and/or heimdal-krb5 building against a once-generated configure run (at least partly), and ports that come with infrastructure/db/config.site which holds a bunch of premade answers to commmon stuff configure scripts look for.
As far as the ports tree goes, full parallelization has been achieved for bulk builds. dpb works just fine, can use as many cores as you throw at it.
These days, the remaining roadblock actually is how much time you can spend preparing machines, setting them up, updating src and xenocara. I'm not kidding, babysitting those machines actually consumes most of the time people spend doing official bulks !
there were a few kinks left before 4.9. All of them have been eradicated now, there is no reason not to use dpb as soon as you have more than one core and want to build sizeables subsets of the ports tree.
By Will Backman (bitgeist) bitgeist@yahoo.com on http://bsdtalk.blogspot.com
By Chris (LizardKing) hatemail@chriswareham.demon.co.uk on http://www.chriswareham.demon.co.uk/
By Chris Bennett (chrisbennett) webmaster@bennettconstruction.us on www.bennettconstruction.us