Hi Bob, Peter, On 17 ก.ย. 2012, at 23:22, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Mon, 17 Sep 2012, Peter Rosin wrote: >>> >>> The 'm4' on this MinGW install is not a blessed version and a simple >>> build/install >>> of latest m4 produces an m4 which does not work. :-( >> >> Was that an MSYS-m4 or a MinGW-m4? Assuming it was MinGW-m4, I > > The one that came with the MSYS install was surely a MSYS-m4 and the one I > built was surely a native Windows m4. The native Windows m4 I built likely > produces/consumes Windows text line terminations and that is why it did not > work (even though libtool configure accepted it).
bootstrap (and Autoconf from where I cribbed the m4 worthiness test) only check the supplied m4 has a version number greater than or equal-to the minimum known working version. The real bug here seems to lie somewhere between modern m4 not building properly on Windows, and Autoconf requiring a newer m4 than supplied by MSYS/mingw. >> think it is too much to ask to require MSYS-tools for simple >> libtool hacking. If it was MSYS-m4, even worse. And the suggestion >> to build a tarball and use that when developing for MinGW is >> just asking too much. Insane work flow. Do people really want to do full-bore Libtool development (as opposed to using it to develop an occasional bugfix) on Windows? Why?!? Not being flippant here, but I'd be surprised to find that the kinds of people who want Libtool to work on Windows, and know enough about Libtool to keep it working don't have access to a pleasant OS for actual development, with Windows relegated to being a test machine. For all the Unix architectures I have access to, my workflow is to put an unpacked `make dist` tarball on an NFS drive, and make VPATH builds in a subdirectory for each machine. Windows has some network mounting facility too, so that doesn't seem insane to me. >> You have to remember that these extra steps lands on the people >> spending the most time fighting (and waiting for) the build >> system. I haven't touched Libtool in a while now, I wonder why, >> but it was not a conscious decision. Maybe it wasn't fun anymore >> for some reason? These changes does not seem attractive though. What changes are you referring to? If there is some particular changeset(s) that have broken previously working Windows support, then we should definitely figure out why, and fix the problem. > Yes. It is important that libtool support Windows really well (with minimum > pain) since I hate Windows so much. This may sound irrational, but a tool > which helps cope with Windows also helps reduce the amount of time spent on > Windows and increases the available time to work on application software. Agreed. But before we can have Windows support on Libtool into the future, at the very least we need someone who is prepared to run semi-regular tests on Windows, and preferably help to diagnose and write patches to fix any problems uncovered. While I sympathise with the horrors of working on Windows, it's not something I want to take responsibility for myself. Particularly as I don't have a Windows license, or any reason to want to buy one. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
