Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Jeff Sickel <jas@corpus-callosum.com>]

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