It is plausible to compile and link the sources of multiple packages on the same command line at the same. (I'm not sure whether this is required for e.g. LLVM's link-time optimization (LTO) but I think it helps the compiler as well.)

The trouble is, the version identifiers used by one package may look strange on the command line and even contradict with another package's:

    dmd -version=use-fibers a/a.d b/b.d

use-fibers? Who is using fibers? Does it have any effect on the other package as well?

So, I think it's a good idea to name-mangle version identifiers with prefixed package names (a-use-fibers instead of use-fibers):

    dmd -version=a-use-fibers a/a.d b/b.d

What do you think?

Is there a way of managing this from the outside? I couldn't do this for a package by introducing a new file that "translates" to what it understands:

version (a-use-fibers) {
    version=use-fibers;
}

I tried putting it in a module and importing by all sources of package 'a' but version did not have affect on the modules that imported it.

String mixins would probably work but it already feels too intrusive to "fix" third party packages like that.

Ali

On 2017-01-16 21:04, Ali Çehreli wrote:
> It is plausible to compile and link the sources of multiple packages on
> the same command line at the same. (I'm not sure whether this is
> required for e.g. LLVM's link-time optimization (LTO) but I think it
> helps the compiler as well.)
>
> The trouble is, the version identifiers used by one package may look
> strange on the command line and even contradict with another package's:
>
>     dmd -version=use-fibers a/a.d b/b.d
>
> use-fibers? Who is using fibers? Does it have any effect on the other
> package as well?
>
> So, I think it's a good idea to name-mangle version identifiers with
> prefixed package names (a-use-fibers instead of use-fibers):
>
>     dmd -version=a-use-fibers a/a.d b/b.d
>
> What do you think?
>
> Is there a way of managing this from the outside? I couldn't do this for
> a package by introducing a new file that "translates" to what it
> understands:
>
> version (a-use-fibers) {
>     version=use-fibers;
> }
>
> I tried putting it in a module and importing by all sources of package
> 'a' but version did not have affect on the modules that imported it.

Yeah, I think it only applies to the module it's set in.

> String mixins would probably work but it already feels too intrusive to
> "fix" third party packages like that.

I don't think it's possible to fix from the outside. I would rather see that the library is adopted for that. Or even better using some kind of config file. With Dub it's possible to generate something like a config file with preGenerateCommands. That config file could look something like:

module liba.config;

version (liba_use_fibers)
    enum useFibers = true;
else
    enum useFibers = false;

Then the library would use "static if" instead of "version" to pick the correct implementation.

Or if the user of the library could supply the config file from the beginning then no version statements are needed. Not sure if that's possible though.

-- 
/Jacob Carlborg

Moving from digitalmars.D.Learn...

tl;dr

It seems to be a good guideline to always name-mangle your version identifiers with the package (and module) name. Otherwise, you will risk confusions and conflicts on the build line.

Ali

On 01/16/2017 11:23 PM, Jacob Carlborg wrote:
> On 2017-01-16 21:04, Ali Çehreli wrote:
>> It is plausible to compile and link the sources of multiple packages on
>> the same command line at the same. (I'm not sure whether this is
>> required for e.g. LLVM's link-time optimization (LTO) but I think it
>> helps the compiler as well.)
>>
>> The trouble is, the version identifiers used by one package may look
>> strange on the command line and even contradict with another package's:
>>
>>     dmd -version=use-fibers a/a.d b/b.d
>>
>> use-fibers? Who is using fibers? Does it have any effect on the other
>> package as well?
>>
>> So, I think it's a good idea to name-mangle version identifiers with
>> prefixed package names (a-use-fibers instead of use-fibers):
>>
>>     dmd -version=a-use-fibers a/a.d b/b.d
>>
>> What do you think?
>>
>> Is there a way of managing this from the outside? I couldn't do this for
>> a package by introducing a new file that "translates" to what it
>> understands:
>>
>> version (a-use-fibers) {
>>     version=use-fibers;
>> }
>>
>> I tried putting it in a module and importing by all sources of package
>> 'a' but version did not have affect on the modules that imported it.
>
> Yeah, I think it only applies to the module it's set in.
>
>> String mixins would probably work but it already feels too intrusive to
>> "fix" third party packages like that.
>
> I don't think it's possible to fix from the outside. I would rather see
> that the library is adopted for that. Or even better using some kind of
> config file. With Dub it's possible to generate something like a config
> file with preGenerateCommands. That config file could look something like:
>
> module liba.config;
>
> version (liba_use_fibers)
>     enum useFibers = true;
> else
>     enum useFibers = false;
>
> Then the library would use "static if" instead of "version" to pick the
> correct implementation.
>
> Or if the user of the library could supply the config file from the
> beginning then no version statements are needed. Not sure if that's
> possible though.
>