On Jan 3, 2008, at 1:55 PM, Luis Lavena wrote:
> For me too, but every time I sent a message to get feedback, three
> things happen:
> A) don't get any reply (quite common)
> B) "move to a real OS" not so funny comments wasting part of my time
> invested (free) on ruby.
> C) another long thread like this with all the problems windows users
> face, the C-lib (MSVCRT) and all that, all over again.
rehash of all the discussion, I've seen before. I was just trying to
get the 'big picture' to understand why Windows is so problematic in
this area.
Another attempt at a big picture summary:
*nix Binary Distribution
-- limited to enclaves (Solaris, MacOSX, Linux) and has all
the same library version problems as with Windows but on any
particular platform there is more continuity between different
libc versions and only a single prevalent compiler avoiding
various object code linkage problems.
Windows Binary Distribution
-- same situation as Unix but the enclaves are Windows variations
of NT, XP, Vista *and* all the different compiler/object code
incarnations. Less common ground to work with. The CLR
is yet another windows binary context to be considered.
*nix Source Distribution
-- standards and common build-chains makes source code
and build processes compatible across wide variety of
systems. Complex packages composed of components from
multiple 3rd parties can be compiled and linked via the
same 'common' build-tool chain (because there is only one
per platform). I realize that autoconf is hideous
but it is one of the reasons for the broad source code
compatibility across *nix platforms.
Windows Source Distribution
-- lack of prevalent compiler and common build-chains makes it
difficult to author and distribute a source code package
that builds and installs correctly in all the different
Windows environments
-- the lack of a common build-chain means that it can be
very difficult to mix-and-match 3rd party source distributions,
which is a much rarer problem in *nix environments.
It seems like the nut to crack is the build-chain environment
in Windows. If the build-chain isn't predictable then it is
going to be pretty hard to avoid an n*m amount of work to get
arbitrary collection of n-packages to work together in m different
Windows environments.
James Tucker wrote:
> Personally, I think the important first stage is to release an
> automated build-chain build-chain. Once we can automate the whole
> stack, we can release it at several independent levels of compilation.
Sounds like the right place to focus developer energy. Also
seems like that a Ruby/Rake combo that could be built with
an absolute minimum of external dependencies would be a great
tool for bootstrapping a full-featured build-chain.
Here is a really crazy idea. Instead of trying to construct
a build environment on each and every Windows box what if the
build environment was available via the Internet? So a small
tool would query the local system and then instruct a remote
system to build the appropriate dlls/applications for the local
machine. Lots of security implications since you would have
to trust the code that was being delivered by the remote
build tool but of course if you are downloading and installing
a build-tool environment you are *already* extending trust to
the provider of the build-tool.
Same idea could be done in the Unix context.
Gary Wright
