Re: Windows compilers

[Ralf Wildenhues]

[ dropping the libtool list ]

Hello Christopher,

* Christopher Hulbert wrote on Thu, May 14, 2009 at 10:37:07PM CEST:
> On Wed, May 13, 2009 at 2:11 PM, Ralf Wildenhues wrote:
> > 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.

If you have these as separate patches, please post them as such, too,
or even better, post a link to a public git archive that has them.

> I wonder if you can call AC_OUTPUT more than once.

No.  Well, I don't know if you can, technically, but it won't do what
you want.

> >> 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.

That's not what I intended to ask for.  I know that func_mode_link is a
mess, and if it were better documented, it would be in the documentation.
I was asking for something that I don't know yet, namely specifically
what you want to have work (not how, but what).  I may be able to tell
you how to do it then.  An answer of the "I'll volunteer to document the
code, or pay someone to fix it" would also have been helpful, but I
didn't ask for that either.

Generally of course, a new port should try to get both testsuites to
pass as many tests as possible, while breaking as little as possible all
existing ports.  The second condition is much more important than the
first, just in case it wasn't obvious already.

Thanks,
Ralf