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

[Peter Rosin]

Den 2010-09-08 07:16 skrev 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.

I don't know how others are going to use this, but my own personal usage
is to create applications that link statically with as many support
libraries as possible to simplify distribution.

>> 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 don't understand what you mean "by default"? Remember that MSVC does
not have any -l option. You specify the exact file name of the library
you want to link with. If it's a simple file name (like foo.lib) MSVC
will traverse the lib search path looking for the library (not sure what
happens if you specify relative/file/name/foo.lib). But the simple file
might as well be foo.dll.lib, that will work splendidly as well. The
drawbacks that I can see are:

1) that MSVC *users* will not feel 100% at home with a file named
foo.dll.lib (as they probably expect it to be named foo.lib).

2) 'compile' will not find foo.dll.lib when it is fed -lfoo. At least not
in its current incarnation. You can say -lfoo.dll to 'compile', but in
that case you might as well say foo.dll.lib since you have made a MSVC
specific hack anyway.

If we take some hypothetical package that was previously built with some
MSVC specific parallel build system that can potentially be obsoleted
by newer autotools, I think the probability that the library naming will
match is low, and I don't really have any interest in doing a survey
into which naming scheme will cause the least number of complaints. The
market is just too diverse. Is there even going to be a majority clique?
Also remember that MSVC specific build systems will probably have
different library names for debug builds as well. In short, I don't
think it will be a drop in replacement for that many projects.

People who build a library using autotools, and then intend to use the
output in some non-autotooled project will have to say either foo.lib
or foo.dll.lib to link with the library. If they don't like foo.dll.lib
they can rename it. A package distributor can do the renaming if it
doesn't match the old scheme.

Anyway, I'm not in the business to create some kind of MSVC-ports
project, I just want to build my own stuff and its dependencies using
MSVC as seamlessly as possible. I'm contributing back to autotools so
that I don't have to fix things again, and it's also fun and a challenge
to make the testsuites as green as possible. Simple as that. As far as
support for MSVC in autotools, it's beyond what I personally need. I'm
for example not using libltdl for anything real.

> 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

Of course it's not the only way, that's why it's hard to decide...

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

I don't know the reason either.

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

My opinion also.

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

Yes, indeed.

Cheers,
Peter