Re: Windows Compilation Madness


On 3 Jan 2008, at 17:04, Gary Wright 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.

No problem, Luis started a thread to discuss the other areas, and I'll
be joining that more actively when I have access to my windows build
chain tools.

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.

Well, there's plenty of common ground to work with, actually, and they
are strongly versioned too. The problem comes later...

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

Indeed. And more than that, it's normally the distro package
maintainers that do any hard work for you.

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

No. The build scripts themselves, are ok. The backing toolchains are
an issue.

There are plenty of prevalent compilers, but there are more options
than on *nix, and the options have more differences.

The core of ruby (i.e. excluding the ext/* stuff) builds just fine
with a normal configure and parse.c pre-built, and compiles just fine
under mingw, and all of the MS compilers. All of them.



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

Source distributions are fine. Again, it's purely a tool chain and
version linkage issue. If a build chain was easy to setup, people
wouldn't find it too hard to understand they need one of three
different binary versions if using pre-built packages, that is, one of
the three different C runtimes that are prevalent. That part of the
issue, I honestly believe, people could deal with. Also, it's
borderline irrelevant for software that doesn't pass around data
structures from one runtime to the next, without altering the data
structures ABI.

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.

It is the build chain that we need to fix.

It's not that many different environments. All of the MS compilers
(for most all of the ruby related software), are actually pretty
identical in terms of the build-time usage. That is, the same command
line works for all of the MS compilers.

MinGW is different, but it's also important as it's the only legal,
currently available compiler that's compatible with VS 6 and the
MSVCRT ("current" runtime).



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.

Right.

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've been thinking about it, but more importantly, something like a
gem build server for building native gems is the first step to *that*
side of it. I'll be working more on this idea in February, as my
company needs something better than my nasty scripts. This will ofc be
released when ready.

What we may want to do (and probably will) is to provide the necessary
pieces to service as a pre-compiled build environment which was built
under the same environment it targets. That is, three or four
different standard binary build sets, for each of the prevalent
compilers. When separated from the rest of the stdlib, and compressed,
this isn't too huge either - I might even be able to front the
bandwidth if we can't do it sanely on rubyforge. I still need to get
into those discussions with the rubygems team, and possibly much later
on Tom Copeland. For the moment, I have much more work to do prior to
that.

Same idea could be done in the Unix context.

Absolutely, I have no intention of locking this to a single context at
all, or hardcoding like GnuWin32 does.



Gary Wright




.

Relevant Pages

  • Re: Windows Compilation Madness
    ... another long thread like this with all the problems windows users ... Less common ground to work with. ... It seems like the nut to crack is the build-chain environment ...
    (comp.lang.ruby)
  • Re: Windows Compilation Madness
    ... another long thread like this with all the problems windows users ... -- standards and common build-chains makes source code ... It seems like the nut to crack is the build-chain environment ...
    (comp.lang.ruby)
  • Re: grid
    ... The notation was invented in the days before there was cross-boundary prototype checking ... in the C compilers. ... He says that the Windows group saw HN, ... compiler, the K&R compiler, that declared all field names as global names, because structs ...
    (microsoft.public.vc.mfc)
  • Compiler positions available for week ending September 16
    ... advertise a position having something to do with compilers and must also ... Software Design Engineer ... The Visual C++ team is working hand in hand with the Windows division ... on enhancing the appeal of Vista and Windows 7 for ISV developers and ...
    (comp.compilers)
  • Handling error/status messages by interface to C++ programs
    ... commercial C++ compilers, such as, for example, Borland compilers, like C++ Builder. ... They can also run either in the console or Windows mode, and send appropriate error and status messages. ... The interface would later display the messages in this or other way. ...
    (comp.object)