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?

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);

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

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.