Setting versions for imports

[div0]

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