On Friday, 16 March 2018 at 07:47:31 UTC, Johannes Pfau wrote:
Am Thu, 15 Mar 2018 23:21:42 +0000 schrieb Jonathan Marler:
On Thursday, 15 March 2018 at 23:11:41 UTC, Johannes Pfau
wrote:
Am Wed, 14 Mar 2018 14:22:01 -0700 schrieb Timothee Cour:
[...]
And then we'll have to add yet another "-import" switch for
DLL support. Now we have 3 switches doing essentially the
same: Telling the compiler which modules are currently
compiled and which modules are part of an external library.
Instead of just using the next best simple solution, I think
we should take a step back, think about this and design a
proper, generic solution.
[...]
I had the same idea but mine was to add this metadata in the
library file itself instead of having it as a separate file.
This is to some degree nicer, as it allows for self contained
distribution. But then you have to support different library
formats, it's more difficult to include support in IDEs and
it's more difficult to extend the format.
It makes the data more difficult to pull from the file but
doesn't make it more difficult to extend. Every library format
supports generic "comment" type data blobs used for things like
this. You could provide a small library to "pull" this data blob
from each supported library format. You would already want to
provide a library for the format itself so that same library
could include the code to pull it from each library format (i.e.
ELF/OMF/COFF). I actually started writing a library in
anticipation for this. Currently it can and print the modules in
an OMF/ELF file by finding the TypeInfo symbols. This could be a
fallback mechanism to use when a library didn't have any
metadata, or even be used to "patch" a library to include
metadata:
https://github.com/marler8997/dlangmodulereader
Of course TypeInfo goes away for code compiled with -betterC so
it doesn't always work, hence why you'd want to add the metadata
beforehand.
However, this
design is "orthogonal" to -i= and -unittest=, in both cases
you may
want to include/exclude certain modules regardless of whether
or not
they are in a library.
When would this be the case for -i?
First, if we were to add the functionality you've talked about
(which I hope we do at some point) this would work alongside -i
not be an alternative to it. The new mechanism would allow us to
ALWAYS EXCLUDE modules that exist in a pre-compiled library. So
we could remove the standard exclusions from -i (-i=-std -i=-core
-i=-etc -i=-object) because those modules would already be
excluded since they would be in phobos. And if a program wasn't
using phobos, then they wouldn't erroneously be excluded. It
just works as it should.
I agree there is no use case where you would want to compile
modules that are in a library passed to the compiler. However,
it's easy to come up with use cases where you want to exclude
imported modules from the compilation even if they aren't in any
library passed to the compiler. In fact, if you're doing any type
of incremental compilation, this will most certainly be the more
common use case since libraries are only passed to the
compiler/linker during the final link stage. For example, maybe
you are compiling a "plugin" that will be linked to another
program but uses a common library that you want to exclude from
your initial compilation, call it "library_for_plugins" i.e.
--- myplugin.d
static import library_for_plugins; // DO NOT compile this module
into the
// plugin library
static import some_other_library; // DO compile this module into
the
// plugin library
void foo()
{
// uses symbols from both modules but that doesn't mean you
want
// to include all of them in compilation
library_for_plugins.foo();
some_other_library.bar();
}
dmd -c -od=obj -i=-library_for_plugins myplugin.d
lib -o myplugin.lib obj\*.o
Of course this is just one example I came up with on the fly. You
could come up with any number of use cases where you would want
this. The point is, this is a compiler, it's job is to compile
modules and there's alot more use cases than just "compile
everything except what's in the libraries I've provided".
