Re: Windows Compilation Madness

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.

I'm not a Windows programmer and I didn't really want to cause a  
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