Jump to page: 1 2
Thread overview
Cross module version specs
Apr 26, 2012
James Miller
Apr 26, 2012
Jonathan M Davis
Apr 26, 2012
James Miller
Apr 26, 2012
James Miller
Apr 27, 2012
bcs
Apr 27, 2012
Marco Leise
Apr 27, 2012
bcs
Apr 27, 2012
Marco Leise
Apr 27, 2012
Matt Peterson
Apr 27, 2012
Dmitry Olshansky
Apr 27, 2012
Matt Peterson
Apr 27, 2012
Walter Bright
Apr 27, 2012
Paulo Pinto
April 26, 2012
I'm trying to write a binding that has conditional sections where some features have to be enabled. I am using version statements for this.

I have a list of version specs in a module by themselves. When I try to compile another module that imports this module, it acts as if the version was never specified. I have tried wrapping the specs inside a version block, then setting that from the command but that doesn't work. Setting the version manually works as expected. I have also tried including the versions file on the command line.

All I can think is that version specifiers aren't carried across modules, which pretty much makes them completely useless unless you only use the built-in versions.

--
James Miller
April 26, 2012
On Thursday, April 26, 2012 12:09:19 James Miller wrote:
> All I can think is that version specifiers aren't carried across modules

They can't be. The only time that versions apply to your entire program is if they're built-in or they're specified on the command line.

> which pretty much makes them completely useless unless
> you only use the built-in versions.

That's not true at all. It just means that versions are either useful for something within a module or they're intended for your program as a whole and passed on the command line (e.g. StdDdoc is used by Phobos, and it's not standard at all; the makefile adds it to the list of compiler flags). But yes, it's true that if you want to define a version in one module which affects another, you can't do it.

The closest that you would be able to do would be something along the lines of having a function in the imported module which returned the version statements as a string which the module doing the importing mixed in. Another option would be to just use static ifs, since they'd be affected by whatever variables or enums where defined in the imported modules. e.g.

static if(is(myVersionEnum1))
{
}
else static if(is(myVersionEnum2))
{
}

- Jonathan M Davis
April 26, 2012
On Thursday, 26 April 2012 at 10:20:37 UTC, Jonathan M Davis wrote:
> On Thursday, April 26, 2012 12:09:19 James Miller wrote:
>> which pretty much makes them completely useless unless
>> you only use the built-in versions.
>
> That's not true at all. It just means that versions are either useful for
> something within a module or they're intended for your program as a whole and
> passed on the command line (e.g. StdDdoc is used by Phobos, and it's not
> standard at all; the makefile adds it to the list of compiler flags). But yes,
> it's true that if you want to define a version in one module which affects
> another, you can't do it.

Is there any reason for that limitation? Seems like an arbitrary limit to me.

The library I am binding to uses ifdefs to let the compiler see the appropriate declarations in the header files. It would be nice in general for D to be able to mimic that capability, as it means you can have a "configuration" file with a list of specs that can be generated at build-time by something like autoconf.

--
James Miller
April 26, 2012
On Thu, 26 Apr 2012 06:32:58 -0400, James Miller <james@aatch.net> wrote:

> On Thursday, 26 April 2012 at 10:20:37 UTC, Jonathan M Davis wrote:
>> On Thursday, April 26, 2012 12:09:19 James Miller wrote:
>>> which pretty much makes them completely useless unless
>>> you only use the built-in versions.
>>
>> That's not true at all. It just means that versions are either useful for
>> something within a module or they're intended for your program as a whole and
>> passed on the command line (e.g. StdDdoc is used by Phobos, and it's not
>> standard at all; the makefile adds it to the list of compiler flags). But yes,
>> it's true that if you want to define a version in one module which affects
>> another, you can't do it.
>
> Is there any reason for that limitation? Seems like an arbitrary limit to me.
>
> The library I am binding to uses ifdefs to let the compiler see the appropriate declarations in the header files. It would be nice in general for D to be able to mimic that capability, as it means you can have a "configuration" file with a list of specs that can be generated at build-time by something like autoconf.

No, it would not be nice, it would be horrible.  C's preprocessor is one of the main reasons I sought out something like D.  The fact that you can include files in a different order and get a completely different result is not conducive to understanding code or keeping code sane.

The correct thing to use for something like this is enums and static ifs.  They work because enums are fully qualified within the module they are defined, and you can't define and use the same unqualified enums in multiple places.

I'll give you some examples:

module1.d:
version = abc;

module2.d:
version(abc) int x;
else  double x;

module3.d:
import module1;
import module2;

pragma(msg, typeof(x).stringof); // int or double?

module4.d:
import module3;

version(abc) int y;
else double y;

pragma(msg, typeof(y).stringof); // int or double?


Now, what happens?  Should module2 be affected by module1's versions?  What about module4?  What if module4 doesn't know that module3 indirectly declares abc as a version?  What if module3 didn't import module1 at the time module4 was written, but added it later?

These kinds of decoupled effects are what kills me when I ever read a heavily #ifdef'd header file.

versions should be defined for the *entire program*, not just for certain files.  And if they are defined just for certain files, define them in the file itself.

-Steve
April 26, 2012
On Thursday, 26 April 2012 at 12:37:44 UTC, Steven Schveighoffer wrote:
> On Thu, 26 Apr 2012 06:32:58 -0400, James Miller <james@aatch.net> wrote:
>
>> On Thursday, 26 April 2012 at 10:20:37 UTC, Jonathan M Davis wrote:
>>> On Thursday, April 26, 2012 12:09:19 James Miller wrote:
>>>> which pretty much makes them completely useless unless
>>>> you only use the built-in versions.
>>>
>>> That's not true at all. It just means that versions are either useful for
>>> something within a module or they're intended for your program as a whole and
>>> passed on the command line (e.g. StdDdoc is used by Phobos, and it's not
>>> standard at all; the makefile adds it to the list of compiler flags). But yes,
>>> it's true that if you want to define a version in one module which affects
>>> another, you can't do it.
>>
>> Is there any reason for that limitation? Seems like an arbitrary limit to me.
>>
>> The library I am binding to uses ifdefs to let the compiler see the appropriate declarations in the header files. It would be nice in general for D to be able to mimic that capability, as it means you can have a "configuration" file with a list of specs that can be generated at build-time by something like autoconf.
>
> No, it would not be nice, it would be horrible.  C's preprocessor is one of the main reasons I sought out something like D.  The fact that you can include files in a different order and get a completely different result is not conducive to understanding code or keeping code sane.
>
> The correct thing to use for something like this is enums and static ifs.  They work because enums are fully qualified within the module they are defined, and you can't define and use the same unqualified enums in multiple places.
>
[snip]
>
> These kinds of decoupled effects are what kills me when I ever read a heavily #ifdef'd header file.
>
> versions should be defined for the *entire program*, not just for certain files.  And if they are defined just for certain files, define them in the file itself.
>
> -Steve

I didn't think about it like that, thanks. I'm planning on just using enums and static ifs in this case now, since it certainly makes more sense and I can achieve the same effect.

Thanks all

--
James Miller
April 27, 2012
On 04/26/2012 03:20 AM, Jonathan M Davis wrote:
> On Thursday, April 26, 2012 12:09:19 James Miller wrote:
>> All I can think is that version specifiers aren't carried across
>> modules
>
> They can't be. The only time that versions apply to your entire program is if
> they're built-in or they're specified on the command line.
>

One monster of a string mixin?

>> which pretty much makes them completely useless unless
>> you only use the built-in versions.
>
> That's not true at all. It just means that versions are either useful for
> something within a module or they're intended for your program as a whole and
> passed on the command line (e.g. StdDdoc is used by Phobos, and it's not
> standard at all; the makefile adds it to the list of compiler flags). But yes,
> it's true that if you want to define a version in one module which affects
> another, you can't do it.
>
> The closest that you would be able to do would be something along the lines of
> having a function in the imported module which returned the version statements
> as a string which the module doing the importing mixed in. Another option
> would be to just use static ifs, since they'd be affected by whatever variables
> or enums where defined in the imported modules. e.g.
>
> static if(is(myVersionEnum1))
> {
> }
> else static if(is(myVersionEnum2))
> {
> }
>
> - Jonathan M Davis

April 27, 2012
On 04/26/2012 05:37 AM, Steven Schveighoffer wrote:
>
> versions should be defined for the *entire program*, not just for
> certain files. And if they are defined just for certain files, define
> them in the file itself.
>

Versions should be defined for the *entire program*, not just for whatever you happen to be compiling right now.

Is there any way to make different modules complain if you link object files built with diffident versions set?
April 27, 2012
On 4/26/2012 3:09 AM, James Miller wrote:
> I'm trying to write a binding that has conditional sections where some features
> have to be enabled. I am using version statements for this.
>
> I have a list of version specs in a module by themselves. When I try to compile
> another module that imports this module, it acts as if the version was never
> specified. I have tried wrapping the specs inside a version block, then setting
> that from the command but that doesn't work. Setting the version manually works
> as expected. I have also tried including the versions file on the command line.
>
> All I can think is that version specifiers aren't carried across modules, which
> pretty much makes them completely useless unless you only use the built-in
> versions.

This is quite deliberate behavior.

Aside from the rationale and other solutions given in this thread, the one I prefer is to define features as functions, and then implement those functions or not depending on the configuration.
April 27, 2012
On Friday, 27 April 2012 at 05:51:36 UTC, Walter Bright wrote:
> On 4/26/2012 3:09 AM, James Miller wrote:
>> I'm trying to write a binding that has conditional sections where some features
>> have to be enabled. I am using version statements for this.
>>
>> I have a list of version specs in a module by themselves. When I try to compile
>> another module that imports this module, it acts as if the version was never
>> specified. I have tried wrapping the specs inside a version block, then setting
>> that from the command but that doesn't work. Setting the version manually works
>> as expected. I have also tried including the versions file on the command line.
>>
>> All I can think is that version specifiers aren't carried across modules, which
>> pretty much makes them completely useless unless you only use the built-in
>> versions.
>
> This is quite deliberate behavior.
>
> Aside from the rationale and other solutions given in this thread, the one I prefer is to define features as functions, and then implement those functions or not depending on the configuration.


I would be with Walter on this.

This is the usual behavior in any other module based language with conditional compilation support. Developers picking up D would be confused, if the behavior would be different here.

--
Paulo

April 27, 2012
Am Thu, 26 Apr 2012 21:22:46 -0700
schrieb bcs <bcs@example.com>:

> One monster of a string mixin?

Take a look at the GtkD sources, more specifically the files in gtkc/ :-)

-- 
Marco

« First   ‹ Prev
1 2