Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!news.mathworks.com!tank.news.pipex.net!pipex!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!daffy!uwvax!dglo From: dglo@tick.SSEC.WISC.EDU (Dave Glowacki) Newsgroups: comp.unix.bsd.netbsd.misc,comp.os.linux.advocacy Subject: Re: DEBATE: BSD vs. Linux Date: 19 Sep 1995 16:49:07 GMT Organization: University of Wisconsin, Space Science and Engineering Center Lines: 58 Message-ID: <43msa3$oau@spool.cs.wisc.edu> References: <4233kp$t8p@hilly.apci.net> <42j4js$lu9@wolfe.wimsey.com> <42m0pg$2lv@klaava.helsinki.fi> <42tat6$l72@senator-bedfellow.MIT.EDU> NNTP-Posting-Host: tick.ssec.wisc.edu Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:1052 comp.os.linux.advocacy:21878 In article <42tat6$l72@senator-bedfellow.MIT.EDU>, Greg Hudson <ghudson@mit.edu> wrote: >Linus Torvalds (torvalds@cc.Helsinki.FI) wrote: >: Forget complex makefiles: try "man lndir". And the nice thing about >: using lndir is that it works for _any_ project, not just your pet >: project that happens to be set up with VPATH etc. > >lndir does not work all of the time. A good many projects like to >write to their source tree during builds, which makes parallel builds >fail. If you're building in the linked tree, any new files will get put there. >lndir also fails to handle source trees containing symlinks to >directories. You can hack this in. >Finally, if any new files or directories are added to >your source tree, the build tree is essentially invalidated and can't >be fixed incrementally. You can hack this in also. >In general, I find it easiest to build packages which do a careful job >of separating out build configuration information from the source files, >and which use a read-only source tree. I maintain a lot of software at >MIT (for six platforms, sometimes more), and I find it takes virtually >zero effort to build or upgrade software packaged by the FSF (which is >usually sensitive to such concerns) or by people who follow their >guidelines. By contrast, building Linux or other products whose >maintainers took a "who cares?" attitude to packaging takes hours of >work to build for many platforms, and I can never be sure that the >result was built properly. Another person and I maintained roughly 1200 binaries from somewhere around 500 software packages for the UC Berkeley Software Warehouse (also supporting six platforms) and used an 'lndir'-like tool called 'lnsrctree'. We also found that it took virtually zero effort for GNU packages, but non-GNU packages were equally trivial once some minor customization was done. I've only recently gotten a 586 machine to use as a home workstation and, using 'lnsrctree', found building even Linux to be no problem. >Random user-level programs can be packaged for parallel build trees >easily: all you need to do is use autoconf, set VPATH in your >Makefiles, and not be too clever. Operating system software doesn't >get to take advantage of the same set of pre-fab tools, but it's >still not very hard. But since most packages on the net don't use autoconf, hacking up a customized Makefile for each architecture is much less work than creating an autoconf file. The current version of 'lnsrctree' hasn't been changed since Nov 1993. If you're really curious about it, you can look at ftp://ftp.CS.Berkeley.EDU/ucb/people/dglo/lnsrctree