From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <30901.1178155962@d.0x1.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A3A5027-DC92-4116-A437-2E99B79255CD@telus.net> Content-Transfer-Encoding: 7bit From: Paul Lalonde Subject: Re: [9fans] speaking of kenc Date: Wed, 2 May 2007 20:57:42 -0700 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 56e91340-ead2-11e9-9d60-3106f5b1d025 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Autohell is caused by an underlying, much more dangerous problem that needs to be addressed: the belief that the myriad POSIX derivatives are somehow "different" systems. The superficial incompatibilities between the lot of them are addressed by auto*, but simple text substitution is insufficient to get around the deeper semantic differences when using non-POSIX. And until a case is made for supporting non-POSIX systems, autohell will continue to thrive, one kludge at a time. I used to be a fan of POSIX standardization, but now see the error of my ways. I know of no way evangelism can succeed against such a firmly entrenched standard, no matter how flawed. The best I think we can do as a community is to keep looking for the killer ap; sadly, I don't think it's in the user space. OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm glad I don't have to implement mmap ;-) Paul On 2-May-07, at 8:39 PM, Adrian Tritschler wrote: > David Arnold writes: > >> -->"Steve" == Steve Simon writes: >> >> Steve> How we can sidestep autohell? >> >> autohell is now a 3-headed beast: automake, autoconf and libtool, >> where some of those are actually multiple components. > > Does any of this really *help* with the business of getting arbitrary > software to compile? The few times I've ever looked into the mess of > (what seems to me) endlessly circular dependencies of tools and > scripts > and configuration files it seems that most of the config. stuff is > busy > fighting *against* auto-blah and trying to simply tell a Makefile > where > to find something. > >> automake is PERL thing that takes a "simplified" Makefile.am, and >> emits a Makefile.in. its added value is understanding how to drive >> libtool, and the creation of Makefiles with standard targets. >> >> autoconf is a Bourne-ish Shell script and a suite of m4 macros. it >> processes various m4 *.in files to produce (at minimum) a Bourne >> Shell >> configure script, and a set of Makefiles. its added value is >> two-fold: a series of HAVE_FOO macros used to compile different code >> fragments, and various other variables substituted into the Makefiles >> to actually compile and link different files. >> >> libtool is another Bourne-ish Shell script that encodes knowledge of >> how shared libraries are built using different linker and >> runtime-linker variants. >> >> i suspect that they probably require bash, GNU m4 and GNU sed. >> automake needs PERL. > > ...each one of which probably needs autoconf, automake and libtool to > build. > >> those porting Python, etc, must have dealt with this somehow? > > Whiskey? > >> d > Adrian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGOV23pJeHo/Fbu1wRAn0mAJ9V3dOplh1hy3KwDXS6O3nP9LRfHgCdFzhQ ekwfjc8+XSHmTRy/AaHSEOQ= =NaA3 -----END PGP SIGNATURE-----