[rust-dev] Deprecating rustpkg

Lee Braiden leebraid at gmail.com
Fri Jan 31 00:50:42 PST 2014

On 31/01/14 08:05, Gaetan wrote:
> Le vendredi 31 janvier 2014, Val Markovic <val at markovic.io 
> <mailto:val at markovic.io>> 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).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/331fb022/attachment.html>

More information about the Rust-dev mailing list