On 31/01/14 08:05, Gaetan wrote:
Le vendredi 31 janvier 2014, Val Markovic <[email protected]
<mailto:[email protected]>> a écrit :
.This is a huge problem in large C++ codebases. It is not fun. An
example: every version of Xerces-C++ puts its code in a new C++
namespace
<http://xerces.apache.org/xerces-c/program-others-3.html>, so code
is in xerces_3_0, xerces_3_1, xerces_3_2 etc to prevent these
kinds of issues.
We did that at work, this seems to be the unique, practical solution.
I don't like when I see a hash in the library file name or symbol
name, but this very efficient for easily manage inter dependency.
This seems like a very wrong-headed approach to me. The Amiga had a
very simple and effective library system, which makes me wonder why
other systems overcomplicate it. It followed rules something like
these, iirc:
1) If a minor change or bugfix happens, increment the minor version.
2) If a major change, which is backwards compatible (i.e., new features)
happens, then increment the major version.
3) When loading libraries, you can specify a major and a minor version,
with 0 for the minor version if you like. You get at least that
version, or better, or the loading fails.
4) If an incompatible change happens, then it's not fulfilling the same
library API any more, so you stop trying to force square pegs into round
holes, and **just rename the damn thing** ;) ;)
Rule 4 seems to be where every other OS's libraries makes a big mistake.
For the internet age, there are new complexities of decentralised forks,
I think we'd need a few more rules:
5) Library names have namespaces, something like Java's (and go's?)
com.org.libname system
6) Anything unofficial (i.e., your patch to version 1.3, bringing it to
an UNOFFICIAL version 1.4) goes in your own namespace, until accepted
into the official codebase, OR you fork your own, NEW, incompatible
library, as in (4)+(5).
--
Lee
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
