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
