www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Versioning in D

reply Sha Chancellor <schancel pacific.net> writes:
I was looking through the versioning examples on the specification.   I 
don't see any examples of an expression.

IE:  
version( API > 4 ) 
{
    ... Something supported in great than version 4 of the API
} else version ( API > 2 ) {
    ... Something supported in great than version 2 of the API
} else {
   ... Some code that only works on really old API versions..
}

Is this supported?  And can imports declare version identifiers?
Jul 23 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Sha Chancellor wrote:

 I was looking through the versioning examples on the specification.   I 
 don't see any examples of an expression.
 
 IE:  
 version( API > 4 ) 
 {
     ... Something supported in great than version 4 of the API
 } else version ( API > 2 ) {
     ... Something supported in great than version 2 of the API
 } else {
    ... Some code that only works on really old API versions..
 }
 
 Is this supported?  And can imports declare version identifiers?


Unfortunately, comparison operators don't work with version (at least 
they didn't last time I tried it). For now, we'd have to do messy stuff 
like this...

version(API_1) version = API_Not_Supported;
version(API_2) version = API_Not_Supported;
version(API_3) version = API_Not_Supported;

version(API_4) version = API_Supported;
version(API_5) version = API_Supported;
version(API_6) version = API_Supported;

version(API_Not_Supported)
{
     static assert(0);
}
version(API_Supported)
{
     // ...
}


As to your other question, I think imports can declare version 
identifiers with the "version = Whatever;"  syntax, but I don't think 
I've ever tried it.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jul 23 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
Maybe we could talk walter into it.. =/  I _really_ don't like the method you
proposed.  No offence, it just looks kludgy. It makes you repeat code for
versions which may have compatible code: 

IE:

version( API_2 ) {
CODE
} else version( API_3 ) {
SAME code
} else 
{
SOME CODE FOR OLD VERSION, which would still get processed on API_4, not just
API_1, which is definately not desired.
}

Walter?  Comments?  


In article <cds3cd$2pva$1 digitaldaemon.com>, J C Calvarese says...

Sha Chancellor wrote:

 I was looking through the versioning examples on the specification.   I 
 don't see any examples of an expression.
 
 IE:  
 version( API > 4 ) 
 {
     ... Something supported in great than version 4 of the API
 } else version ( API > 2 ) {
     ... Something supported in great than version 2 of the API
 } else {
    ... Some code that only works on really old API versions..
 }
 
 Is this supported?  And can imports declare version identifiers?


Unfortunately, comparison operators don't work with version (at least 
they didn't last time I tried it). For now, we'd have to do messy stuff 
like this...

version(API_1) version = API_Not_Supported;
version(API_2) version = API_Not_Supported;
version(API_3) version = API_Not_Supported;

version(API_4) version = API_Supported;
version(API_5) version = API_Supported;
version(API_6) version = API_Supported;

version(API_Not_Supported)
{
     static assert(0);
}
version(API_Supported)
{
     // ...
}


As to your other question, I think imports can declare version 
identifiers with the "version = Whatever;"  syntax, but I don't think 
I've ever tried it.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jul 23 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Sha Chancellor wrote:

 Maybe we could talk walter into it.. =/  I _really_ don't like the method you
 proposed.  No offence, it just looks kludgy. It makes you repeat code for
 versions which may have compatible code: 


Yep. It's a definitely a kludge.

I complained about the lack comparison operators in version a long time 
ago. I think Walter replied to it, but it was more "maybe someday" than 
"oh, I'll get right on that." I don't recall anyone bringing up this 
issue recently. I've become resigned to the reality that we'll probably 
have to make it work the way it is. Kludgy, yes. Impossible, I don't 
think so.

Maybe D 2.0 will have some cool new versioning facilities.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jul 23 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
In article <cdsae0$2vtc$1 digitaldaemon.com>, J C Calvarese says...

Sha Chancellor wrote:

 Maybe we could talk walter into it.. =/  I _really_ don't like the method you
 proposed.  No offence, it just looks kludgy. It makes you repeat code for
 versions which may have compatible code: 


Yep. It's a definitely a kludge.

I complained about the lack comparison operators in version a long time 
ago. I think Walter replied to it, but it was more "maybe someday" than 
"oh, I'll get right on that." I don't recall anyone bringing up this 
issue recently. I've become resigned to the reality that we'll probably 
have to make it work the way it is. Kludgy, yes. Impossible, I don't 
think so.

Maybe D 2.0 will have some cool new versioning facilities.



I would think that this is a rather important feature.  Maybe we should tie
walter up and force him to code :)  Does he add features if we donate funds
toward it?
Jul 23 2004
parent J C Calvarese <jcc7 cox.net> writes:
Sha Chancellor wrote:

 In article <cdsae0$2vtc$1 digitaldaemon.com>, J C Calvarese says...
 

Sha Chancellor wrote:


Maybe we could talk walter into it.. =/  I _really_ don't like the method you
proposed.  No offence, it just looks kludgy. It makes you repeat code for
versions which may have compatible code: 


Yep. It's a definitely a kludge.

I complained about the lack comparison operators in version a long time 
ago. I think Walter replied to it, but it was more "maybe someday" than 




Perhaps the "maybe someday"-ish response was in my head. I think I found 
the old thread that I was remembering. Here's where is starts:
http://www.digitalmars.com/drn-bin/wwwnews?D/18144

I just now looked at the old thread. It seemed to be a 
Walter-vs-everyone else thread where most posters complained that 
version isn't as flexible as #define.

(My old post is in there somewhere, but it's neither the most important 
post in the thread nor as cool as I remember it.)


"oh, I'll get right on that." I don't recall anyone bringing up this 
issue recently. I've become resigned to the reality that we'll probably 
have to make it work the way it is. Kludgy, yes. Impossible, I don't 
think so.

Maybe D 2.0 will have some cool new versioning facilities.


 
 
 
 I would think that this is a rather important feature.  Maybe we should tie
 walter up and force him to code :)  Does he add features if we donate funds
 toward it? 


LOL.

I don't think Walter can be bought. I think he enjoys working for 
himself too much.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jul 23 2004
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Sha Chancellor wrote:

 I was looking through the versioning examples on the specification.   I 
 don't see any examples of an expression.
 
 IE:  
 version( API > 4 ) 
 {
     ... Something supported in great than version 4 of the API
 } else version ( API > 2 ) {
     ... Something supported in great than version 2 of the API
 } else {
    ... Some code that only works on really old API versions..
 }
 
 Is this supported?  And can imports declare version identifiers?


It is supported through the back door.

version = 4; or -version=4 on the commandline will do

version (3) {
   // left out
}

version (4) {
   // compiled
}

version (5) {
   // compiled
}

There is also the possibility for an else clause:

version (4) {
   // compiled
}
else {
   // left out
}

The docs say:

-version=level
   compile in version code >= level

Note that for
-debug=level
   compile in debug code <= level


Lars Ivar Igesund
Jul 24 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
In article <cdt152$ip1$1 digitaldaemon.com>,
 Lars Ivar Igesund <larsivar igesund.net> wrote:


 It is supported through the back door.
 
 version = 4; or -version=4 on the commandline will do
 
 version (3) {
    // left out
 }
 
 version (4) {
    // compiled
 }
 
 version (5) {
    // compiled
 }
 
 There is also the possibility for an else clause:
 
 version (4) {
    // compiled
 }
 else {
    // left out
 }
 
 The docs say:
 
 -version=level
    compile in version code >= level
 
 Note that for
 -debug=level
    compile in debug code <= level
 
 
 Lars Ivar Igesund



This doesn't fix the problem I described.   For example:  In MacOS 9 and 
below there are different versions of the API as declared in defines.   
For some cross-version compilation you need #if API_VERSION < 3 #endif 
crap going on.   But there is different version numbers for different 
APIs.   While this might work if i only ever used one module.   It 
doesn't fix the problem.


It's also flawed in another way:  Maybe version(4) {} and version (5) {} 
code are mutually exclusive but you want to compile version 4?  How is 
that accomplished.
Jul 24 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Sha Chancellor wrote:



The docs say:

-version=level
   compile in version code >= level

Note that for
-debug=level
   compile in debug code <= level


Lars Ivar Igesund


 
 
 
 This doesn't fix the problem I described.   For example:  In MacOS 9 and 
 below there are different versions of the API as declared in defines.   
 For some cross-version compilation you need #if API_VERSION < 3 #endif 
 crap going on.   But there is different version numbers for different 
 APIs.   While this might work if i only ever used one module.   It 
 doesn't fix the problem.
 
 
 It's also flawed in another way:  Maybe version(4) {} and version (5) {} 
 code are mutually exclusive but you want to compile version 4?  How is 
 that accomplished.


Well, note that I switched debug and version above :). This means that 
specifying version=4 will compile in version 4. Version=5 will compile 
in both (as is logical).

Alas, AFAICS, only one version integer can be used in one compilation. 
Thus you probably need to use string identifiers and nested version 
statments for the more complex stuff, but this might not be enough 
either, at least not without doubling up the code. The best (and just a 
little bit more complex) solution would probably be to be able to 
specify integers like this (or similar)

-version[ONE_API]=4 -version[OTHER_API]=7

and then have expressions that can use ONE_API and OTHER_API like you 
sketched in your first post.

Lars Ivar Igesund
Jul 24 2004