Re: autoconf in pure MSVC environment?

[Russ Allbery]

Brandon J Van Every <address@hidden> writes:

> It has happened on too many projects to be a specific issue.  It is the
> general nature of the Windows beast.  Poor support for UNIX-oriented
> projects because of little vetting.  There are thousands of open source
> projects available on Sourceforge alone.  I spent a lot of last year
> downloading and trying to build a lot of 'em.  They cannot all be dealt
> with by talking to project maintainers - asssuming the maintainters were
> even willing to do something.

> The better approach is to have a universal tool which aids in fixing the
> problem.  I said, after last time, I will not try to tackle these
> problems by manual labor again.  Either get some kind of Autoconf going
> for MSVC, or give up on moving code from UNIX to MSVC as not usually
> worth the bother.

That would be neat, but we don't even have that sort of tool for
cross-compatibility between different Unix varients, let alone to a
completely different operating system nearly as different from Unix as VMS
is.  If I write any non-trivial software package using Autoconf, I still
have to port it when I move it to IRIX, HP-UX, AIX, etc.  I rarely get so
lucky as to have it just work the first time, and then it has to be
regularly tested on those other platforms in order to keep it working.
There's the sys/select.h thing on AIX, differences in how to define a
32-bit integer, lots of mmap differences, now IPv6 portability issues,
alloca, large file support issues, etc.  Each time one of the old ones
finally goes away (strdup is now portable, as is #include <string.h>), new
ones crop up in features that people want to use.

It's an admirable goal, although I'm not sure Autoconf is going to be an
easy way of achieving it, but it doesn't solve the fundamental problem
you've correctly identified.  For that software to work reliably on
Windows, someone is going to have to regularly test it on Windows and fix
it, or the Windows support, however it's done, is going to bitrot and stop
working.  The same, really, is true of all porting work.

> I don't agree.  Even if Cygwin / Mingw builds get a lot better, there
> are still valid reasons to port to MSVC.  And, I don't see that
> arbitrary open source authors will *ever* be forced to provide good
> build maintenance, just because of a mailing list about Cygwin packaging
> admonishing them to do so.

Oh, of course not.  Given that arbitrary open source authors are generally
not being paid to work on their projects at all, and almost certainly are
not being paid to work on porting them to Windows, there's no way to force
them to do anything whatsoever.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>