On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote:
Are you talking about a list of import statements here or is
there another way/place I would list them?
On the dmd command line. So say your program has a.d and b.d, you
would compile with `dmd a.d b.d`.
Or as you had some success with, the newer compilers let you just
do `dmd -i a.d` and it finds the rest based on the import
I'm not sure what you mean by 'library' in this statement.
For example, since you are using gtkd.lib, you don't have to
include all of gtkd's source files. (The compiler needs to be
able to FIND them, but you don't have to list them.)
If you were using a makefile, you may only list one file at a
time to compile each separately, then link together all the
generate .obj files as a separate step.
Just still trying to understand when it would be necessary to
use a prefix and dot separator in an import statement.
The most practical answer is "always".
There's some exceptions that work for simple cases, but even then
you put yourself at potential conflicts if some library author
decided to pick the same name.
So you are really better off just always using some prefix and
always listing the full name.
at the top of every file in your source tree. (Or you can use
more dots if you want to further subdivide it, like
And when importing it, always list the full name, exactly the
same as you listed it in the module definition.
Every time you use it, from any location. Then it will work in
all cases, whether compiling all at once (which I recommend btw),
or using a makefile, or any other build system, even if you
decide to bring in more libraries or your program grows beyond
the super simple cases.
You can organize the subfolders based on those dot names (or do
the dot names based on the subfolders if that is existing) and
that will ease the process a bit more. But regardless of the
folder layout and file locations, always use the full names and
be sure they match in module and import statements.
when I compile rather than compiling modules over and over
Oh, lots of us compile everything at once. It works quite well
and is fast for many applications that you don't need to do
Does D have the concept of makefiles? I haven't run across any
reference to such things so far.
Yes, you can use a makefile with D basically the same as with C.
But you may find it actually builds slower than just dmd -i