Date: Wed, 19 Jun 1996 19:30:55 -0700 From: Josh MacDonald <jmacd@CS.Berkeley.EDU> To: current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <199606200230.TAA01704@paris.CS.Berkeley.EDU> In-Reply-To: Your message of "Wed, 19 Jun 1996 18:29:40 PDT." <199606200129.SAA14683@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Has anyone thought seriously about how difficult it would be to write a tool that automatically bmakes a piece of software? I think the place to start would be tracking make dependencies to determine everything that goes into a binary. Has everyone seen the recently added GNU tool automake-1.0? Its pretty neat. If GNU utilities start using automake to generate their makefiles, then a similar utility, or even a modification of the same, could serve to easily bmake a GNU distribution. If GNU Makefiles start being distrubuted with Makefile.am's, the problem is solved, since the Makefile.am's contain precisely the information required to build a set of Makefiles. It would be a few perl scripts that plug into automake (or someone elses program) to modify a GNU distribution into a bmaked version of the same. The documentation distributed with automake makes it sound as if GNU Makefile maintainers have collaborated to design this utility so they can use it on the large packages. >From the sound of your discussion, it sounds like another tool would be required to unbmake a tree, just to restore the original pathnames so that diffs are easy to calculate, since CVS can't do this for us. I've spoken out on my dislike for the tendency to keep old versions of critical programs such as gcc around in the source tree, and while I like the bmake paradigm, I think its worth doing whatever it takes to make incorperating new versions of these utilities easy. -josh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606200230.TAA01704>