Joe Nardone wrote:

>>> I noticed there are no MD(d), MT(d) suffixes at the end of targets' names
>>> neither in Makefile.vc* makefiles nor in the VC project file curllib.vcproj.
>>> Do you avoid this VC naming convention by any purpose?
>> I think nobody of those who added the targets in the first place was aware
>> of any such naming convention and then the rest of the targets were added to
>> following the existing convention.

>> If you ask me, we need to get something other to fix this
>> windows-build-hell. Adding 2041 different makefile targets for all sorts of
>> build config combinations doesn't feel sane. But then there's no
>> "configure"-like standard tool or so for Windows so I don't really know what
>> this other and better way would involve! :-/

Splitting targets to orthogonal concepts would be a good start - instead
of having "release-half-a-dozen-of-combinations" and at the same time
"debug-half-a-dozen-of-THE-SAME-combinations" we should have
CFG1=debug|release CFG2=the-rest which results in reduction of explicit
targets by the factor of 2.
The same goes for dynamic/static.

> I don't think there's much choice. This is the tactic that both OpenSSL
> and Boost take, for example, generating 6 or 8 different outputs for the
> various permutations (static vs. shared, debug vs. release, single vs.
> multithread).

Being able to build the lib with any combination of used libs (and their
types) is good.

> I don't know how much I'd call it a convention, but there is
> precedence. Of course,
> they do use different naming schemes...

I don't have problems with targets' names like ssl, ssl-dll, zlib-dll
and so on.
Talking about targets I had in mind output files rather than targets'
names. So for any target using static RTL it's common in VC to have MT
suffix in names of output files (libcurlMT.lib, libcurlMT.dll) and so on.

Regards
Piotr Dobrogost
Received on 2009-02-18