Re: Target platforms

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Nov 27, 2009 at 12:51:07PM -0800, Nathan Kurz wrote:

> >> Making MSVC a first class citizen would be fine if you think the return
> >> is there.
> >
> > No, as far as I'm concerned MSVC is a compatibility target.
> >
> > I think it's important for our users to provide wide portability, and that
> > means supporting MSVC.  E.g. I want somebody's platform-portable wiki
> > project or MVC framework to be able to integrate Lucy without hesitation.
> 
> If the goal is limited to this, would it would to target GCC and release
> binary DLL's?  

That would complicate distribution and limit flexibility.  Check out the kind
of difficulties that people go through to get things compiled and installed:

    http://rubyforge.org/pipermail/rubyinstaller-devel/2009-March/000499.html

I want to leave open as many options for packaging Lucy as possible, by making
it as easy to build as possible.  

As a matter of principle, I don't think Lucy ought to be a monoculture
programming project, bound to any particular compiler platform.  We should be
working towards greater popularization of standards, not contributing to
balkanization.  The Lucy core should stay portable.

As a matter of practicality, portability is not that heavy a burden for Lucy
relative to other projects of similar scope.  Not that much of the core code
has to deal with OS and compiler platform dependency issues.

Nevertheless, I'm up for creative solutions that allow us to loosen the
syntax constraints without costing us too much in terms of compatibility.

> If we don't take the easy way out above, would a 'by any means
> necessary' clause allow us to compile in C++ for MSVC?

I'm cautiously optimistic that this approach will work.  I've managed to get
both Lucy and KinoSearch to build and pass tests under MSVC as C++.  

We're not quite done yet.  I'm about 75% confident that I understand the
linking implications of building under C++ with MSVC and that it's not going
to make it any harder to build a DLL that exports all the necessary symbols.

To confirm, we should prioritize something I've put off for a little while:
binding the C tests into one shared object and the core library into another.

I'd also like to confirm that we can build and link against MSCVRT.DLL.

If all goes well... it would be nice if Charmonizer stayed C89, but everything
else, I think it makes sense to require that the compiler support your three
high-priority C99 features:

> '//' style comments

> variadic macros

> declarations anywhere you want

There are other systems we'll be leaving behind, but they're mostly older.
MSVC is the blocker.

Marvin Humphrey