> 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,
···
On Jan 3, 7:04 pm, Gary Wright <gwtm...@mac.com> wrote:
On Jan 3, 2008, at 1:55 PM, Luis Lavena wrote:
--
Luis Lavena