digitalmars.D - Versioning best practices
- Lars Ivar Igesund (62/62) Jan 24 2007 I've been looking at what D and the compilers provide to help with
- Thomas Kuehne (33/38) Jan 24 2007 -----BEGIN PGP SIGNED MESSAGE-----
- BCS (7/25) Jan 24 2007 Shouldn't version be used for adding or not adding a feature? I'm
- Thomas Kuehne (18/37) Jan 25 2007 -----BEGIN PGP SIGNED MESSAGE-----
- BCS (2/19) Jan 25 2007 Ah, that is a bit of a differnt concept.
- Lars Ivar Igesund (13/52) Jan 25 2007 Thus the conclusion is that version statements are not generally suitabl...
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
-----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 * new GC features * changed member names for some TypeInfo classes 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
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Ivar Igesund schrieb am 2007-01-24: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.)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".
Jan 24 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BCS schrieb am 2007-01-24: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 -----BEGIN PGP SIGNATURE----- iD8DBQFFuPsgLK5blCcjpWoRAhY0AKCs40FgnpbtBHPzjyGJTIjA8ehARgCeIW8J Sq/5DhbsuAMXdFNk07GTi4o= =Xc4r -----END PGP SIGNATURE-----Lars Ivar Igesund schrieb am 2007-01-24: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*.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".
Jan 25 2007
BCS <BCS pathlink.com> 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. ThomasAh, that is a bit of a differnt concept.
Jan 25 2007
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BCS schrieb am 2007-01-24: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 TangoThomas 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. ThomasLars Ivar Igesund schrieb am 2007-01-24: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*.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".
Jan 25 2007