Re: [PATCH] Adjust naming of MSVC import libraries.

[Ralf Wildenhues]

* Peter Rosin wrote on Wed, Sep 08, 2010 at 12:23:17AM CEST:
> Den 2010-09-07 22:24 skrev Ralf Wildenhues:
> > * Ralf Wildenhues wrote on Tue, Sep 07, 2010 at 10:20:06PM CEST:
> >> * Peter Rosin wrote on Tue, Sep 07, 2010 at 11:25:00AM CEST:
> > Rationale: you don't, and can't, and won't, be able to require other
> > tools to use the 'compile' script.  And you do want to be compatible
> > with what MSVC does by default anyway.  And you don't want to implement
> > a search algorithm in the compile script either.
> 
> That's old :-) A few messages back in the thread:
[...]

Hmm.  I thought this whole exercise had as one goal being able to create
drop-in packages that could be and would be used by other software
created by MSVC, and possibly by other build systems.  IOW, the "when
in Rome" thing.  I admit that I've never seen this spelled out
explicitly, but it seemed like a desirable goal, also, to foster
adoption of this type of building.

> If you want to move the output from a libtoolized project into some
> MSVC project, you can always require the user to rename as you move
> the foo.dll.lib file, or simply specify foo.dll.lib in the project
> file. But agreed, random MSVC users will probably think that
> foo.dll.lib looks suspicious if they have to say that in the project.

And it will not link correctly by default, right?  Not just for MSVC
projects, also for whatever other build system is in use.

I won't veto this decision, if you guys are convinced that this is the
only and the true right way to go, but if you do, then this has got to
be the most important piece of information to be added to the Libtool
and Automake manuals of all the w32 changes (both the semantics and
probably also a short rationale).  We get oodles of user questions why
we don't create a DLL linked against a static w32 lib (and I'm not even
sure why we do, except for some abstract notion of portable consistency).

> Is the lib search just out of place in 'compile'? Do you fear the
> performance penalty of doing (another) scripted lib search?

That's one thing (and yes, I think 'compile' should be as dumb as
possible).  I think the interoperability thing weighs in more, though.

> I guess the list of negative issues is quite long...

Well, API design decisions are the most important and hardest ones to
make, since you're pretty much stuck with them once the genie is out of
the bottle.

Thanks,
Ralf