Farid Zaripov wrote:
-----Original Message-----
From: Travis Vitek (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 1:22 AM
To: stdcxx-dev@incubator.apache.org
Subject: [jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature


[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atla
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#actio
n_12552933 ]
Travis Vitek commented on STDCXX-675:
-------------------------------------

If the new user takes advantage of the autolinking feature, they will have to modify their build system to get it to work with a previous version of the library. i.e. they will need to explicitly link the library file when they go back to 4.2.0.

  You're right, but what the type of incompatibility of this case? :)
Source? - No, because there no source changes. Binary? - No again :)

I agree, it's a gray area.

The general rule of thumb I tend use for maintenance releases is that
they must be hassle-free drop-in replacements for each other. I.e., it
should be just as easy to swap in the previous release into a project
built with a maintenance release as it is in the opposite direction.
The safest way to achieve this goal is to refrain from implementing
any enhancements in maintenance releases and restrict changes to
bug fixes only. Even then, though, an argument could be made that
if a user program builds against the maintenance release and relies
on a bug fix implemented in the release they may not be able to
simply drop in a prior version and expect the program to work as
before.


Will this ever be useful for any compiler other than MSVC and ICC/Windows?

  Yes, if the autolinking feature will be implemented there :)

Is there a way that we can ensure the user links the right library on all platforms?

  We can define some symbol in the library with the unique name
for the each build type, and make the reference to this symbol
in <config.h>. Then in case the linking with incorrect library
the "undefined symbol reference" linker error will be issued.

It might be worth exploring this idea a bit before making a decision.
If it turns out we're not completely comfortable with the solution
for 4.2.1 there's always 4.3.

Martin


This wouldn't avoid the need to explicitly link the library, but it would eliminate issues with linking the wrong library.

  Right.

Farid.


Reply via email to