From: Luis Lavena <luislavena@...>
Date: 2008-01-04T07:10:11+09:00
Subject: Re: Windows Compilation Madness

On Jan 3, 7:04 pm, Gary Wright <gwtm...@mac.com> wrote:
> 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.
>

On *nix, all the binaries must be compiled and linked to the same
version of the C runtime.

On Windows, different programs can use its own copy of the C runtime
(MSVCRT), use the system wide one or different version available also
system-wide.

Share libraries (dlls) loaded by some application cannot mix the C
runtimes.

> *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.
>

I'll like to quote your message in a future blog post regarding this
issue :-)

> 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.
>

Been under that road :-)

> 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.

I was about to provide a windows "tinderbox" so gem developers can get
windows builds of their gems for free, without the need of get windows
+development tools and the pain it is.

There is also CruiseControl as CI tool, that could be used too.

Thank you Gary for your comments,

Regards,
--
Luis Lavena