pr-msvc-support rules and issues (was: Re: pr-msvc-support: building .DLLs with symbols)

[Peter Rosin]

Den 2009-09-10 11:48 skrev Peter Rosin:
> Here's a couple of patches that implements support for -Wl, and
> -Xlinker for MSVC. The first one 
> (rename-dashL_envvar-tolinker_envvar.patch)
> is just a rename, to reduce confusion, and the second patch
> (-Xlinker-msvc.patch) contains the new code...
>
> Ok for the pr-msvc-support branch?

Ping? David did say it works for him...

I also want these patches commited ASAP since other branches
in my git tree needs to be slightly tweaked because of these
patches and it would just be easier to put that behind me
instead of carrying different branches forward depending on
the future of these two patches.

What are the rules for the pr-msvc-support branch anyway? I have
a whole bunch of patches that I would like to push, some of them
I have not even bothered to send for review since the queue is
so long and the dependencies on other non-approved patches makes
it hard to describe how to apply them correctly. What I'm saying
is that my git tree is getting closer and closer to a forrest
and I'm getting tired at looking at testsuite failures only to
discover that I have already solved the issue but that it was
so long ago that I didn't even recognize the failure as an old
failure at first.

Personally, I want reviews and acks of anything going in there,
since anything else is just going to come back and haunt us when
it's eventually time for the merge.

Which reminds me of the four commits that I pushed by mistake
to the branch, namely:
fbc144008bd66848111fb8ef2d7293b33957ea1a skip-on-no-reload
8c17887ee34e73a2aeb127b94f5b76f45dc34017 msvc-doc
2817364bb6efd255550192c46edecfe085cbb288 embed-manifest
8c17887ee34e73a2aeb127b94f5b76f45dc34017 libtool-ar

Apart from the fact that the commits have very dubious dates,
and the fact the Ralf told me to leave them there, the last one
(libtool-ar) must be given some attention before we merge. I have
some further patches and some integration with automake to make
lib.exe work better on that front, but I don't think it is any
point in showing that before the following happens:

I would really really like to see Chucks cross-compile-cwrapper
patches pushed, that would significantly clean up my git
dependencies and generally make my life easier (apart from paving
the way to get the MinGW failure fixed in stresstest.at with low
max_cmd_len, I have patches for that sitting and waiting, and
MinGW is GNU so should receive a higher priority than some
obscure MSVC patches). Pretty please!

Cheers,
Peter