httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Jam
Date Tue, 30 Sep 1997 07:47:32 GMT

Anyone heard of a replacement for "make" called "Jam"?  Chris is the author
and thinks we could really benefit from it.  I warned him it would take
some work to try a new system since our Makefiles are auto-generated by
configure, but he seems to think it'll be worth it.  Anyone know anything
about it?  I told him to hold off until 1.3b1 before submitting it.


>Date: Fri, 19 Sep 1997 16:51:56 -0700 (PDT)
>From: Christopher Seiwald <>
>Subject: Re: Jamfile for apache 1.3
>| First - wait until next week when 1.3b1 comes out.  We've done a fair bit
>| of makefile/Configure revamping.  Also realize that the makefiles are
>| auto-generated by our own Configure program, so the benefits of using Jam
>| are going to have to be big for us to do this.
>OK.  I'll wait.  Much of the configure output could be reused for Jam input.
>| Second - could you give me the 5-bullet-point (etc.) overview of why Jam is
>| better than (gnu/bsd/etc) make?  
>>From the web page:
>	Jam is a make(1) replacement that makes building simple things
>	simple and building complicated things manageable.
>	Jam's language is expressive, making Jamfiles (c.f. Makefiles)
>	compact. Here's a sample:
>	   Main smail : main.c map.c resolve.c deliver.c
>			misc.c parser.y alias.c pw.c headers.c
>			scanner.l getpath.c str.c ;
>	This builds "smail" from a dozen source files. Jam handles header
>	file dependencies automatically and on-the-fly.
>	Jam is very portable: it runs on UNIX, VMS, NT, OS/2 and Mac MPW. 
>	Most Jamfiles themselves are portable, like the sample above.
>	Jam is unintrusive: it is small, it has negligible CPU overhead,
>	and it doesn't create any of its own funny files (c.f. Odin,
>	nmake, SunOS make).
>	Jam can build large projects spread across many directories in
>	one pass, without recursing, tracking the relationships among
>	all files. See the accompanying paper. On UNIX and NT, jam can
>	do this with multiple, concurrent processes.
>	Jam isn't under the blinkin GNU copyright, so you can incorporate
>	it into commercial products.
>If that isn't enough, let me know.  The second to the last point is
>not to be underestimated: jam's dependency analysis isn't dependent
>on the order in which you build things -- it does the whole monty.
"it's a big world, with lots of records to play."-sig

View raw message