Re: [lmi] building with Visual C++

[Greg Chicares]

On 2008-02-03 17:37Z, Vadim Zeitlin wrote:
> On Sun, 27 Jan 2008 17:34:35 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> As for msvc:
> GC> 
> GC>  - It would be nice to support one more compiler
> ...
> GC>  - It's also an advantage if an additional compiler has (or works
> GC>    with) useful tools for error detection beyond usual compiler
> GC>    diagnostics, as in the case you mention.
> GC> 
> GC>  - OTOH, it's not relevant that msvc is popular in some segment
> GC>    of the non-free (software) world: lmi needs to support a
> GC>    monopoly compiler "like a fish needs a bicycle".
> 
>  There is unfortunately one other reason to use MSVC which I believe I
> already mentioned but would like to repeat:
> 
> - Debugging in MSVC is incomparably more efficient than using gdb
> 
> While I agree with your view that ideally debugging should be avoided
> completely, sometimes debugger is still a very useful tool to have. And
> MSVC debugger is really very good
[...]
>  Another reason is that compiling using MSVC is so much faster

Okay.

>  So I'd really appreciate a possibility to be able to build LMI with this
> compiler, this could save us a lot of time.

I don't object to anyone using another toolchain. The more we
can support, the better--as long as gcc is supported at least
as well as any non-free tools.

I would balk at writing all 'mc_enum.[ht]pp' function bodies
inline just because (defectively, AFAICT) msvc refuses to
compile it as is. I find it clearer the way it is, and IIRC
there are significant advantages to keeping it that way:
better compile-time error detection, and probably also better
compiler or linker performance.

But I'd accept an alternative msvc-specific version, e.g., in
a different file. I do understand that a parallel compiler-
specific version of the same code is harder to maintain
correctly, but there are unit tests to guard against that.
At any rate, using the nomenclature here:
  http://gcc.gnu.org/gcc-4.2/criteria.html
gcc is primary; I'd like comeau to become secondary, though
that'll take more work; and msvc is at most tertiary until
it can compile lmi without workarounds.