Brandon J Van Every <vanevery@xxxxxxxxxxxxxxxxxxx> writes: > Russ Allbery wrote: >> 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. > Yes but Autoconf helps you *resolve* those differences quickly, yes? > That's my point. If Autoconf can't solve the portability problem, it > can at least serve as a good aid to porting. Granted, yes. Autoconf is a good toolkit for doing those sorts of probes on Unix. I worry that it's been designed around a mindset that was pretty much exclusively focused on Unix at the time and that extending it to do the sorts of probes one wants to do on Windows is going to result in a bit of a mismatch, though. Hm. Perhaps this is the best question to ask (I don't know the answer, not being familiar at all with Windows programming): Does the basic Autoconf model of generating a script that writes out small programs and then seeing if they'll compile and/or run and produce correct results make sense as a probe mechanism on Windows? Autoconf uses the compiler as it's primary and nearly it's only probe into the configuration of the system, and if that paradigm works on Windows, maybe it will be a good tool for Windows porting. If Windows prefers other techniques to establish the configuration of the system (querying the registry, checking the OS version, running other programs, I don't know what), then Autoconf may not work very well, since Autoconf really wants to establish all or nearly all of its knowledge by running the compiler and observing its behavior. -- Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
