On Tue, 23 Oct 2012 18:49:45 -0500, Rob T <r...@ucora.com> wrote:
I may be getting messed up by the way modules map directly to folder
structures, and how to separate an interface from the implementation.
Eg. import A.m1;
I understand that the above import requires that a folder "A" be found
at the root level of the source folder (where ever it may be), and
module m1.d must be located directly in A. So far so good, however A may
be located in a folder outside of the current project. For example, the
std lib imports are located outside you projects root folder (this is a
goal to acheive what I want to reproduce with my own D prebuilt
libraries).
When I try to import from another project located in another set of
folders, how do I tell the compiler to start looking at a certain point?
For example
/projects/
/p1
/src
/A
/B
/C
/p2
/src
/D
/E
/F
With the above folder structiure, how can I get this to work?
import A.m1;
import D.m2;
I would say the above folder structure doesn't make much sense for a
single program, unless those are third-party libs.
The -I flag specifies where to look for imports, but go one folder above
the A/ . So assuming we are in projects/:
rdmd -Ip1/src -Ip2/src
Notice there is no space between -I and the folder to look at. You could
run the command from the bin/ dir if you have one, which will dump the obj
in bin/ (rdmd -I../p1/src ...) or you can use the -of flag.
It seems to be pretty similar to C, C++...
I've used make on a project before, but make is a clusterfuck IMHO. I
think I spent more time simply RTM for make than getting anything to work.
I generally just create a file 'DBuild' with this:
#!/bin/sh
rdmd -IimportPath main.d
And then modify it as necessary.
I may be able to manually get something to work, but how can it be
automated with scons? I know I'll have to manually supply the project
search paths somehow, but will scons be able to figure out that "import
D.m2;" means to look under /projects/p2/src/D/?
I know nothing about scons.
Also if I make an edit to D/m2.d will scons be able to figure out that
D/m2.d needs to be rebuilt and/or that all files that import D/m2.d must
be rebuilt?
rdmd will, don't know anything about scons.
In C/C++ full rebuilding is only required when header files (.h) are
modified and included, not when the implementation is modified. How do
we make the distinction between the interface and the implementation in
D?
Perhaps I should be building interface files (.di), how is that done and
how do you refer to them after they are built?
either -H flag or manually. -H pretty much just strips the comments
since certain constructs need the full source.
If you write a library and want to hide the source, then you can write .di
files just like .h files, which include minimal source. But just like cpp
macros, certain things (templates I believe are one) must be defined in
the .di file.
The functions can simply be declared.
Check out the deimos project, which is a collection of bindings to C
libraries. The .di files there should show you
what is necessary. https://github.com/D-Programming-Deimos
Nothing better than learn-by-example.
Finally how do you specify an alternate folder for dumping the build
stuff to separate it from being dumped into your source folders? Also
how to you specify an installation folder, eg /usr/local/bin along with
location of necessary import folders. I definitely do not want to
install full source code so that imports will work, so I assume the .di
files are installed instead.
I just use shell scripts.
or -of flag. Or running dmd from that directory, so it outputs there.
There are many many ways to do this.
Or use rdmd, which compiles and runs, but doesn't output obj files except
in /tmp
I know I'm asking a lot of basic questions which means I havn't much
clue how to build D apps yet, so are there any good examples or
documentation I can look at that will supply me with the answers?
Phobos uses Make files I believe, vibe.d simply recompiles vibe.d plus
your code usually.
ps: I'm an experienced C++ programmer, so the tendancy is to replicate
the same practice, however I'm definietly open to better ways that make
the most out of D.
Thanks for any help you gave give!
--rt
It's largely the same... There might be others who can give better advice,
but it seems to be scons, shell files, dmd/rdmd flags, Make, CMake... not
necessarily in order of preference.
There's an old tool called dsss, but I've never had any luck with that one.
I recommend running dmd --help and reading the output. It's pretty self
explanatory.
http://dlang.org/pretod.html#headerfiles That one might be useful.
http://dlang.org/cpptod.html This one is specifically for C++
programmers.
But neither of those discuss building.
Someone correct me if I've made a horrible mistake somewhere...
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
