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