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?

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);

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.

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

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

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??

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

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

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.

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.