On Wed, May 13, 2009 at 2:11 PM, Ralf Wildenhues <ralf.wildenh...@gmx.de> wrote: > Hello Christopher, > > * Christopher Hulbert wrote on Wed, May 13, 2009 at 01:14:47PM CEST: >> 1. What's the future of that branch? Is it ever likely to merge into >> master to become part of a libtool release and have a larger support >> base? > > Bob addressed this already. > >> 2. Based on (1), should I use/modify that branch or make modifications >> to my own copy of master. I already have a branch modified from master >> that works well with PGI on Windows. > > Well, you can show what you have. If it overlaps a lot with the branch, > it would likely be good to base it on that.
It was pretty close to the master before I started adding some stuff for the Intel compilers. It's still not nearly as different as the pr-msvc-support branch. Then again, I have not tested it extensively and I am not intimately familiar with the libtool script, so I am likely missing some cases. Anyways, the diff and logs are attached. I've also CC'd the patches list. > >> 3. Checking for non-libtool libraries using autoconf (e.g. Intel MKL) >> requires knowing whether the compiler uses the MSVC or -L/-l format >> when linking (at least for the few platforms I am working with). Is it >> possible to develop an LT_TRY_LINK m4 macro that can handle that? >> Unfortunately I think the libtool program is not created until the end >> of the configure script. Would a macro like LT_TRY_LINK even be >> desired by other libtool users? Perhaps it already exists? > > You can use LT_OUTPUT which will create the libtool script right then. Interesting. I'll have to check that out. I was thinking it was done the same way as AC_CONFIG_FILES. I wonder if you can call AC_OUTPUT more than once. > >> 4. Not being a shell-scripting black-belt and not having a lot of time >> to spend analyzing the libtool source, the 8000+ line ltmain.m4sh >> program is extremely difficult to navigate. I have managed relatively >> small hacks to it, but some sort of flowchart might be really nice for >> people like myself. Yes, I realize that it takes people time and >> effort to develop, so don't think I'm just nagging for it. I would be >> happy to help with it, but again I don't understand enough of libtool >> to make it happen. > > Please describe the things you want to have work or the issues you see > (both as high level as you can possibly do, as well as as specific as > you can do, with a command sequence showing failures). One issue is func_mode_link is gigantic. If I counted right, it's on the order of 4000+ lines. Trying to find where certain steps occurred has been a little rough. If there was some sort of flow chart that showed the steps in there with pointers into the source, that would be helpful. Chris > > Thanks, > Ralf >
hulbert_windows.tar.gz
Description: GNU Zip compressed data