OpenBSD Journal

groff deleted from tree

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)


Comments
  1. By Adam P (adamrt) fakeempire@gmail.com on

    Great job guys. I'm impressed. Keep up the great work!

  2. By phessler (phessler) spambox@theapt.org on http://theapt.org

    erm, we still have c++ in base. Mesa.

    Comments
    1. By Paul 'WEiRD' de Weerd (weerd) on http://www.weirdnet.nl/openbsd/

      > erm, we still have c++ in base. Mesa.

      Yes, sorry - I meant in src/

  3. By phessler (phessler) spambox@theapt.org on http://theapt.org

    This makes compiling so much faster, especially on our slower arches. Horray!

    Comments
    1. By Amit Kulkarni (amitkulz) on http://forestlaw.blogspot.com

      > This makes compiling so much faster, especially on our slower arches. Horray!

      One more thing holding back fast compiles is the configure scripts, which just can't be made to do it in parallel.

      Comments
      1. By Janne Johansson (jj) on http://www.inet6.se

        > > This makes compiling so much faster, especially on our slower arches. Horray!
        >
        > 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
        1. By Marc Espie (espie) espie@nerim.net on

          > > > This makes compiling so much faster, especially on our slower arches. Horray!
          > >
          > > 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.

  4. By Will Backman (bitgeist) bitgeist@yahoo.com on http://bsdtalk.blogspot.com

    Excellent! Thank you everyone for the hard work.

  5. By Chris (LizardKing) hatemail@chriswareham.demon.co.uk on http://www.chriswareham.demon.co.uk/

    Cool! Looking forward to this hitting NetBSD -current as well, hopefully in time for NetBSD 6.0.

  6. By Chris Bennett (chrisbennett) webmaster@bennettconstruction.us on www.bennettconstruction.us

    Thanks, great to see this happen

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]