On Tue, 2012-10-23 at 14:17 +0200, Paulo Pinto wrote:
[…]
> Even worse is having new generations of developers learning that the 70's way of Make and Autotools is the way to go.

I suppose one could attempt a (failed from the beginning) analogy with
programming:

1950s approached gave way to 1970s approaches which gave way to 1990s approaches which gave way to 1930s approaches.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, Oct 23, 2012 at 09:56:21AM +0100, Russel Winder wrote:
> On Mon, 2012-10-22 at 12:54 -0700, H. S. Teoh wrote:
> […]
> > Does it use the dmd tool by default? How do I select the gdc tool instead? I tried env.Append(tools = 'gdc') but it didn't make any difference.
> 
> I will have to check what the default tool is, in the case where multiple valid D toolchains are installed, there may be a problem there.
> 
> environment = Environment(tools=['gcc', 'gnulink', 'gdc'])
> 
> is known to work.

That worked wonders. Thanks!!


> There are issues here that we are trying to fix relating to how C, C++, Fortran and D all interwork. An upshot of the problem is that, for now, the gdc tool must come last in the sequence. :-(( I know, but…

Well, in my case, neither dmd nor gdc are in $PATH, but I specified the full path in DC. Is there a way to have SCons notice the last component in the path (the compiler name) and adjust accordingly?


[...]
> > I'm going to take a shot at building a .deb for the latest git gdc-4.7 branch, which AFAIK should support at least 2.059 (and maybe 2.060?).  It's probably non-trivial, as the debian gcc build scripts are a tangled labyrinth I've yet to unravel. :)
> 
> You can certainly put me on the list of people to test such a thing.
> 
> My only need is that it must be harmonious with the Debian Unstable install so that it can be installed and uninstalled without disrupting the standard Debian 4.7.
[...]

I'm using Debian unstable as well, so I'll try my best to make sure the package is non-disruptive.


T

-- 
Change is inevitable, except from a vending machine.

You know there's a really big problem to solve when getting Make to build properly can be more difficult than gettiing the program it is supposed to be building to work.

My biggest problem with D right now, is that I cannot easily build anything of significance, even with Make which I know quite well, or scone, which I know next to nothing about at this point (just started using it).

I've tried scons with the D support, but I have had the same issues as has been reported in here, so it's been a very rough ride.

I may be having two problems, one with understanding how D apps are supposed to be built, and problems with the build tools that are still in development.

Currently I am trying very hard to get rid of Make, really I don't have much choice because AFAIK there's no easy way to get a useful dependency list out of gdc or dmd that can be used with Make. There is an option to produce a dependency list, but the output seems to be useless because it does not include full path for some of the dependecies, and the format is wrong to boot (needs Make to run an editor to clean up), and cgd 4.7 has a bug with producing the output rendering it totally useless (I'll try and report this bug on the tracker, now that I have an account).

Given the significant problems I'm experiencing, I really wonder how anyone is building anything of significance in D? Since it appears that significant apps are being built, I figure I'm trying to do things in a C/C++ way when I am expected to do things in a different "D way".

Can anyone point me towards documentation that explains the best practices to build D apps? I'm not talking about simple one file programs, but multiple files that may have dependencies spanning across alternate project folders.

--rt

On Tue, Oct 23, 2012 at 11:35:29PM +0200, Rob T wrote: [...]
> Currently I am trying very hard to get rid of Make, really I don't have much choice because AFAIK there's no easy way to get a useful dependency list out of gdc or dmd that can be used with Make. There is an option to produce a dependency list, but the output seems to be useless because it does not include full path for some of the dependecies, and the format is wrong to boot (needs Make to run an editor to clean up), and cgd 4.7 has a bug with producing the output rendering it totally useless (I'll try and report this bug on the tracker, now that I have an account).

SCons can figure out the dependencies without needing to be told explicitly. That is, if it's working correctly. Currently I do have multi-file D projects, but they haven't grown into multi-folder projects yet, so admittedly I don't have too much experience in that area.


> Given the significant problems I'm experiencing, I really wonder how anyone is building anything of significance in D? Since it appears that significant apps are being built, I figure I'm trying to do things in a C/C++ way when I am expected to do things in a different "D way".
[...]

Well, dmd tends to work best when given the full list of D files, as opposed to the C/C++ custom of per-file compilation. (It's also faster that way---significantly so.) The -op flag is your friend when it comes to using dmd with multi-folder projects.

And I just tried: gdc works with multiple files too. I'm not sure how well it handles a full list of D files, though, if some of those files may not necessarily be real dependencies.


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

On 23 October 2012 22:58, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Tue, Oct 23, 2012 at 11:35:29PM +0200, Rob T wrote: [...]
>> Currently I am trying very hard to get rid of Make, really I don't have much choice because AFAIK there's no easy way to get a useful dependency list out of gdc or dmd that can be used with Make. There is an option to produce a dependency list, but the output seems to be useless because it does not include full path for some of the dependecies, and the format is wrong to boot (needs Make to run an editor to clean up), and cgd 4.7 has a bug with producing the output rendering it totally useless (I'll try and report this bug on the tracker, now that I have an account).
>
> SCons can figure out the dependencies without needing to be told explicitly. That is, if it's working correctly. Currently I do have multi-file D projects, but they haven't grown into multi-folder projects yet, so admittedly I don't have too much experience in that area.
>
>
>> Given the significant problems I'm experiencing, I really wonder how anyone is building anything of significance in D? Since it appears that significant apps are being built, I figure I'm trying to do things in a C/C++ way when I am expected to do things in a different "D way".
> [...]
>
> Well, dmd tends to work best when given the full list of D files, as opposed to the C/C++ custom of per-file compilation. (It's also faster that way---significantly so.) The -op flag is your friend when it comes to using dmd with multi-folder projects.
>
> And I just tried: gdc works with multiple files too. I'm not sure how well it handles a full list of D files, though, if some of those files may not necessarily be real dependencies.
>
>

To compile multiple modules into one object file, you need to specify '-o', else it compiles one-at-a-time.  Otherwise it should work pretty well...

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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 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/?

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?

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?

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 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?

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

On Tue, 23 Oct 2012 18:49:45 -0500, Rob T <rob@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 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/?
>
> 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?
>
> 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?
>
> 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 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?
>
> 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
>
rdmd -Ip1/src -Ip2/src appThatImports.d

Or dmd appThatImports.d p1/src/A/m1.d p2/src/B/m2.d.
But you might still need the -I flag for the second, I don't remember...

I prefer simply using rdmd and -I flags to figure out the import paths.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

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

I'm trying to do a very simple build, but with scons I find myself spending much more time with it (and getting nowhere) than the actual coding, and that tells me that it's no better and may be even worse than Make.

As an example of the sort of nonsense scons dishes out, I cannot in a reasonable way, specify a build folder above my root source folder, such a thing should be extremely easy to specify, but no it isn't.

I also found that scons is lacking basic features that any build tool should have. For example, when I tried to generate a list of my source files, I discovered that scons it has no built in ability to recursively scan a folder to include all subfolders. WTF!?

I know I can write custom code in python to get around these problems, but that will depeat the entire purpose of having a build tool in the first place.

scons also comes with a ton of dependency baggage that I simply do not need, therefore I am giving up on it entirely.

At this point I'm considering looking at those old build tools written in D, perhaps I can patch one of them up to get it to do what I want.

If anyone has a suggestion as to which of the (I think) 2 or 3 build tools coded in D looked the best, that would be appreciated.

--rt

On Wednesday, 24 October 2012 at 02:35:11 UTC, 1100110 wrote:
> I would say the above folder structure doesn't make much sense for a single program, unless those are third-party libs.

Yes, that would be for storing separate libraries, each of which will be independent projects separate from the others. Of course other projects are expected to make use of the libraries, and some libraries may make use of other libraries, which means at least some of the projects will require access to the source interfaces of some of the others.

I would expect that this kind of organization is standard practice, otherwise you'll have a lot of otherwise unnecessary difficulties keeping projects clean and identifiably separate.

If anyone can suggest alternate ways of organizing projects, I'll be happy to read about it.

--rt