www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Versioning best practices

reply Lars Ivar Igesund <larsivar igesund.net> writes:
I've been looking at what D and the compilers provide to help with
successfully versioning D source code in such a way that it minimizes
duplication of code (and in the process ease organization of said code),
ease readability and ease building.

As it is, D provides several tools, but they seem to me to be somewhat
disjoint. What I'd like to hear, is if there is a combination of the
existing features (that makes sense) that will achieve the above to at
least some degree.

First, what is versioned and thus may affect the application builder:
* The compiler, e.g. DMD 0.178, 1.00, 1.001, GDC 0.20, 0.21
* The specification, currently only D1.0 (there may be issues with this, but
I won't go into it here)
* Libraries having their own release schedule (and which probably depend on
one or both above in some fashion)

The tools:
* version statements - This is a very good feature for separating the
features of the application or the library, but requires the set versions
to be passed through the command line
* std.compiler - This module contains all the relevant version numbers;
compiler, spec and also the vendor. These numbers can not be used in the
version statements.
* static if - a very useful feature that can compile in parts of the code
using the numbers in std.compiler, but if that is a suggested solution,
then it _really_ should be possible to use these constants in a version
statement.
* the -v1 switch - this is to make sure that D code complies to the D1.0
spec, but does this mean that code that is conditionally excluded (for
instance because it is post D1.0 code) need to syntactically comply to
D1.0?

Problems:
A couple are mentioned above, especially that values in std.compiler cannot
be used in version statements. A possible solution to this, would be that
the compiler defines these as preset versions, but then again currently
only one (and unnamed) integer version can be supplied, and it is not
possible to say that you want the spec version to be >= D1_0 (or a similar
preset version identifier).

Does this mean that one really should not version code (in the source) on
any of the above criteria (compiler version or spec version)? I'm not
necessarily opposed to this, as after some versions, there will be a lot of
statements and may become hard to manage.

The alternative is (afaics) to use a version control system and actively tag
revisions as the need arise, and then properly document which versions of
what are supported, and possibly provide a more complex build setup (maybe
even something akin to autoconf).

As was mentioned in some other thread, now that the new GC (supposedly not a
breaking change) is not working properly, the current versioning scheme of
spec and compiler, still seems somewhat raw.

Do you think that the current tools are adequate?
What would then be the best way to use them?
Can we still refine conditional compilation to make some of this
easier/better looking?
Are there other problems or tools (I'm mostly talking about language and
compiler features here, not external tools, although that may be part of
the solution) that I have not mentioned that should be considered?

I believe some of the above are more of an issue in D than in other
languages, partially because the tools may not be sufficiently useful, but
also because D is as of yet a fast moving target.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango
Jan 24 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lars Ivar Igesund schrieb am 2007-01-24:
 I've been looking at what D and the compilers provide to help with
 successfully versioning D source code in such a way that it minimizes
 duplication of code (and in the process ease organization of said code),
 ease readability and ease building.

 Do you think that the current tools are adequate?

Most of the times versioning is the wrong approach. I think C's (and to a lesser extend C++'s) non-existing compile time reflection forced everyone to use versioning instead of "featuring". I'll use Flectioned[1] as a sample. the problem: support 5 different D APIs * dmd-1.001 * dmd-1.00 * dmd-0.177 * gdmd-0.21 * gdmd-0.20 ("Normal" programs shouldn't notice the differences, they are however crucial for Flectioned.) the solution: * targeted operation system / binary format # flectioned.d:755: version(linux){ * new GC features # flectioned.d:495: static if(is(typeof(si.flags))) * changed member names for some TypeInfo classes # flectioned.d:1443: static if(is(typeof((new typeof(ti)()).value))) The rest is done with generic logic that handles issues like mangling bugs without requiring "static if" or "version". Thomas [1] runtime reflection for D: http://svn.dsource.org/projects/flectioned/downloads/flectioned.zip -----BEGIN PGP SIGNATURE----- iD8DBQFFt72BLK5blCcjpWoRAmqFAJwLl/JxUvleQOZg8Hp0Kobe1RK5AACeOiqm ksJcBKVM89w4qa3fwbffOh4= =Ezzn -----END PGP SIGNATURE-----
Jan 24 2007
parent reply BCS <BCS pathlink.com> writes:
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Lars Ivar Igesund schrieb am 2007-01-24:
 
I've been looking at what D and the compilers provide to help with
successfully versioning D source code in such a way that it minimizes
duplication of code (and in the process ease organization of said code),
ease readability and ease building.

[...]
Do you think that the current tools are adequate?

Most of the times versioning is the wrong approach. I think C's (and to a lesser extend C++'s) non-existing compile time reflection forced everyone to use versioning instead of "featuring".

Shouldn't version be used for adding or not adding a feature? I'm thinking of, for example, building a compiler with extensions where the extensions are optional*. (* This could be done with run time switches, but try building a parser with yacc that at run time can turn on or off any set of 20+ syntax extensions.)
Jan 24 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BCS schrieb am 2007-01-24:
 Thomas Kuehne wrote:
 Lars Ivar Igesund schrieb am 2007-01-24:
 
I've been looking at what D and the compilers provide to help with
successfully versioning D source code in such a way that it minimizes
duplication of code (and in the process ease organization of said code),
ease readability and ease building.

[...]
Do you think that the current tools are adequate?

Most of the times versioning is the wrong approach. I think C's (and to a lesser extend C++'s) non-existing compile time reflection forced everyone to use versioning instead of "featuring".

Shouldn't version be used for adding or not adding a feature? I'm thinking of, for example, building a compiler with extensions where the extensions are optional*.

Maybe we have different concepts of versioning. C: #if USE_REENTRANT #if GLIBC > 1 The first line is a feature test while the second one is a version test. If you use D's "version(...)" to check features that's fine. Versioning in the strict sense(line 2) however is usually not a good design - unless your are trying to bypass some library bugs, though fixing those should be the primary approach. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFuPsgLK5blCcjpWoRAhY0AKCs40FgnpbtBHPzjyGJTIjA8ehARgCeIW8J Sq/5DhbsuAMXdFNk07GTi4o= =Xc4r -----END PGP SIGNATURE-----
Jan 25 2007
next sibling parent BCS <BCS pathlink.com> writes:
Thomas Kuehne wrote:
 
 
 Maybe we have different concepts of versioning.
 
 C:
 #if USE_REENTRANT
 #if GLIBC > 1
 
 The first line is a feature test while the second one is a version test.
 If you use D's "version(...)" to check features that's fine.
 
 Versioning in the strict sense(line 2) however is usually not a good
 design - unless your are trying to bypass some library bugs, though fixing
those
 should be the primary approach.
 
 Thomas
 

Ah, that is a bit of a differnt concept.
Jan 25 2007
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 BCS schrieb am 2007-01-24:
 Thomas Kuehne wrote:
 Lars Ivar Igesund schrieb am 2007-01-24:
 
I've been looking at what D and the compilers provide to help with
successfully versioning D source code in such a way that it minimizes
duplication of code (and in the process ease organization of said code),
ease readability and ease building.

[...]
Do you think that the current tools are adequate?

Most of the times versioning is the wrong approach. I think C's (and to a lesser extend C++'s) non-existing compile time reflection forced everyone to use versioning instead of "featuring".

Shouldn't version be used for adding or not adding a feature? I'm thinking of, for example, building a compiler with extensions where the extensions are optional*.

Maybe we have different concepts of versioning. C: #if USE_REENTRANT #if GLIBC > 1 The first line is a feature test while the second one is a version test. If you use D's "version(...)" to check features that's fine. Versioning in the strict sense(line 2) however is usually not a good design - unless your are trying to bypass some library bugs, though fixing those should be the primary approach. Thomas

Thus the conclusion is that version statements are not generally suitable for handling versions in the sense that it is mostly used, but for feature differentiation only. Maybe it should be called feature statement instead? ;) It do however pave a future road for a more complex build tool that can handle versioned dependencies with grace. Quite possible that DSSS are close, though. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi Dancing the Tango
Jan 25 2007