On Sat, 2005-08-27 at 09:02 -0400, Seth Kurtzberg wrote:
Ross Paterson wrote:
For some packages that interface to C libraries, configure solves a real problem on Unix systems, and we need a way to solve that problem on Win32. It might be enough to include Win32 versions of the files that configure generates, and on Win32 to just copy those instead of running configure.
I would suggest that, while configure does solve a problem, it isn't the best way to solve the problem. A properly abstracted and layered implementation of O/S specific calls, with each environment supported by an implementation file, is much closer to "doing the right thing."
[snip]
However, people wanted to know why it didn't use configure. If configure identifies the environment and copies the correct files, that would satisfy the need for consistency (that is, for this package you use ./configure just as you do for many other packages). Using the methodology of configure, in my mind, is embracing ann ugly philosophy.
I think the problem here is not the configure philisophy but its implementation using standard unix tools. That obviously doesn't work on windows. However the idea of configure I think is sound. Instead of creating a bit of code for each platform you want to support you identify features of the environment instead (ie "does ld support the '-x' flag on this system?"). That way you can port to systems you'd never thought of, or cope with changes in a target platform more easily. Duncan