Setting versions for imports

Bill Baxter dnewsgroup at billbaxter.com
Tue Oct 2 13:46:54 PDT 2007


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


More information about the Digitalmars-d-learn mailing list