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
