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