From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <437259C9.5010003@lanl.gov> <0E7FF0EA-61C0-4806-9533-070EAFAAEF30@lanl.gov> <43726187.8000806@lanl.gov> <4372C2A2.1090802@lanl.gov> <98C8D026-907D-4DAB-8A12-05C964625FA4@corpus-callosum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C859518-1ED3-4AC3-942D-1046CA69A688@corpus-callosum.com> Content-Transfer-Encoding: 7bit From: Jeff Sickel Subject: Re: [9fans] plan9ports & macos 10.4 don't like each othere. Date: Thu, 10 Nov 2005 01:30:01 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: aa88169c-ead0-11e9-9d60-3106f5b1d025 On Nov 9, 2005, at 11:53 PM, Russ Cox wrote: > > Please don't assume that I've properly queued things > that I don't respond about. I completely missed the > mkfile change in your mail. I think the other changes > (in 9l) have been applied for a few weeks. If there are > any changes you think I'm still missing, please resend them. Sorry about the assumption bit on my part. Sometimes juggling so many different source trees gets to be confusing, though I'll admit that after seeing the cleanup of the mkfiles and changes in the plan9port of a period of time, I've been convinced to move more projects into a similar vein. >> Would anyone mind if I made the required changes to 9c, 9l and any >> supporting mkfiles? > > I would mind. It's a pain that .o is the same suffix everywhere, > but it's a fact of life on Unix. If the code got ported to Windows > using MSVC (looking less likely now that I know about mingw), > I would fully expect to use .obj. Trouble is.. and this comes from doing many multi-architecture ports on NEXTSTEP (68040, x86, HPPA, Sparc) to PowerPC and subsequent uses of macho formats for Darwin, I've found that on the few OSs where you actually get to deal with various hardware, having a build system that's somewhat sane and tells you which object files go with what can be a fantastic thing (a big thank you to the architects of Plan 9). > Plan 9 from User Space walks a fine line between avoiding > the ugliness of Unix and trying to coexist peacefully with it. > I think it would be too radical a change if you ran 9c and got > a .8 file out, especially given that the .8 would actually *be* a .o. > It would be a different story if it were a Plan 9 .8 file. 9l > generates > a.out for the same reason. It's difficult to articulate exactly > where the line is in general, except that I built an earlier system > that tried to be much more like Plan 9 (it had all the system calls > and a user-level kernel that all the "Plan 9" applications talked to). > It succeeded at being more like Plan 9 but it failed at being > useful. It felt like I had built another world on top of the host > system (Windows in this case). The current tools feel more > integrated into the host system, and I like that a lot. The current Xcode build environment philosophy is an unfortunate bastardization of the old ProjectBuilder Makefiles melded through a brief period of Jam and finally into their hell-born XML based build system that ends up creating awful subdirectories for each target object file and only at the end linking them all together in a 'fat' binary (US Patent No. 5,432,937) that is usable on 'any' current Mac OS X architecture as long as it includes your natively linked symbols and hasn't been run through lipo (gotta trim the fat somehow). But since very few people build 68040, HPPA, or Sparc versions of code w/ Apple's version of gcc, it isn't too much of a problem. The current Plan 9, plan9ports and Inferno build environments offer what I've come to consider as a much more sane system for bootstrapping on each host/terminal. I'd just like to see a little more of that carry over into other environments as much as possible. > Also, using .8 and .q instead of .o still wouldn't be completely > specific: > as I move between FreeBSD and Linux I frequently find myself > staring at .o files and having no idea which system they're > compiled for. mk clean; mk. Agreed. Though as more of the BSD and Linux distributions become multi-architecture capable, it will be more and more of a mess to wade through the various output their separate versions of gcc, gas, and gnu ld end up producing. I just think that the plan9port example is a good start on cleaning up that kind of build process mess. jas