www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cross module version specs

reply "James Miller" <james aatch.net> writes:
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
Apr 26 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Apr 26 2012
next sibling parent reply "James Miller" <james aatch.net> writes:
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
Apr 26 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 26 2012
next sibling parent "James Miller" <james aatch.net> writes:
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
Apr 26 2012
prev sibling parent reply bcs <bcs example.com> writes:
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?
Apr 26 2012
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 26 Apr 2012 21:24:46 -0700
schrieb bcs <bcs example.com>:


 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?


You would need to modify the linker (optlink/ld) to understand that two object
files compiled by a D compiler include a section that informs it about enabled
version tags, or maybe abuse existing systems to the end that the poor
programmer mixing versions up gets a generic error message that doesn't make
any sense.

But more importantly, you can bundle up object files into .a archives aka
static _libraries_ with yet another tool, I think ar is its name. It would not
work out if e.g. GtkD compiled its static libraries with one set of versions
and you compile your app with another set. Or in contrast, you would have to
enable versions like 'cairo_new_backend', 'druntime_use_old_gc',
'whatever_any_other_object_file_was_compiled_with' for your program, even if
you don't need them.

To sort that mess out again, the compiler would have to create a list of
versions that affect the currently compiled module at all. It would then find
out that for your program 'druntime_use_old_gc' is irrelevant and exclude it
from the version check.

                      my_app  GtkD  Phobos  <conflicts?>
my_ver                on      -     -       no
unused                off     -     -       no
cairo_new_backend     -       on    -       no
druntime_use_old_gc   -       -     off     no
debug                 on      off   off     yes
X86_64                on      -     on      no

In this case the linker would complain only about a version named 'debug' that
was enabled in your application, but not for the object files of GtkD and
Phobos.

-- 
Marco

P.S.: Can I have a software patent on this?
Apr 27 2012
prev sibling next sibling parent reply bcs <bcs example.com> writes:
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
Apr 26 2012
parent Marco Leise <Marco.Leise gmx.de> writes:
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
Apr 27 2012
prev sibling parent reply "Matt Peterson" <ricochet1k gmail.com> writes:
What about a templated module?

     module test(bool option1, T);

Imported like this:

     import test!(true, Foo);

It could act like the entire module was wrapped in a template, 
and the import would become:

     import test;
     mixin test.test_template!(true, Foo);
Apr 27 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28.04.2012 0:22, Matt Peterson wrote:

 What about a templated module?

 module test(bool option1, T);

 Imported like this:

 import test!(true, Foo);

 It could act like the entire module was wrapped in a template, and the
 import would become:

 import test;
 mixin test.test_template!(true, Foo);


I would rather see this as import test with specified version identifiers.

import test!(some_version);
//imports module but treats it contents as if with "version = 
some_version;" added at the top of it


-- 
Dmitry Olshansky
Apr 27 2012
parent "Matt Peterson" <ricochet1k gmail.com> writes:
On Friday, 27 April 2012 at 20:26:38 UTC, Dmitry Olshansky wrote:

 I would rather see this as import test with specified version 
 identifiers.

 import test!(some_version);
 //imports module but treats it contents as if with "version = 
 some_version;" added at the top of it


This is inconsistent with the syntax and the way templates work 
in the rest of the language, as well as being a lot less flexible.

It wouldn't be hard to mixin a string built from a list of 
identifiers passed in to set those versions.
Apr 27 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Apr 26 2012