Make [was Re: SCons and gdc]

1100110 0b1100110 at gmail.com
Tue Oct 23 19:30:26 PDT 2012


On Tue, 23 Oct 2012 18:49:45 -0500, Rob T <rob at 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/


More information about the Digitalmars-d mailing list