I've just finished a project in D and have been using rdmd to compile during testing. While this is nice, i now want to try other compilers to see if i get any speed gains.

Because i use rdmd it takes care of passing everything to dmd. Now i want to try GDC and i need to pass the files in the correct order for compilation. I've first tried to write a bash script with all the files listed correctly and passed all the necessary flags to dmd but i can never get the order of the files correct.

There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.

Any ideas? How do you handle compiling projects with 50+ source files?

On Thu, Aug 01, 2013 at 07:46:05PM +0200, Gary Willoughby wrote:
> I've just finished a project in D and have been using rdmd to compile during testing. While this is nice, i now want to try other compilers to see if i get any speed gains.

Based on my experience, you will, with gdc / ldc. The optimizers in gdc/ldc are much more mature than in dmd; I've compared the disassembly and measured running times with gdc -O3 vs. dmd -O, and gdc consistently produces code that performs 20-30% faster. YMMV, of course, since the exact amount of speed gain depends on what your code does.


> Because i use rdmd it takes care of passing everything to dmd. Now i
> want to try GDC and i need to pass the files in the correct order for
> compilation. I've first tried to write a bash script with all the
> files listed correctly and passed all the necessary flags to dmd
> but i can never get the order of the files correct.

Huh? It shouldn't matter what order the files are. If it does, it sounds like a bug!


> There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.
> 
> Any ideas? How do you handle compiling projects with 50+ source files?

Use a real build system. ;-)  I recommend SCons (http://scons.org/) or tup (http://gittup.org/tup/). Both require some amount of learning to use effectively, though. If all else fails there's always makefiles, but I rather use them only as a last resort.


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.

Am Thu, 01 Aug 2013 19:46:05 +0200
schrieb "Gary Willoughby" <dev@nomad.so>:

> I've just finished a project in D and have been using rdmd to compile during testing. While this is nice, i now want to try other compilers to see if i get any speed gains.
> 
> Because i use rdmd it takes care of passing everything to dmd. Now i want to try GDC and i need to pass the files in the correct order for compilation. I've first tried to write a bash script with all the files listed correctly and passed all the necessary flags to dmd but i can never get the order of the files correct.
> 
> There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.
> 
> Any ideas? How do you handle compiling projects with 50+ source files?

Doesn't rdmd have a verbose flag or something to dump the executed commands? Then you could just copy and paste it from there. You could also try to make rdmd work with gdc but I think there was some problem with rdmd and gdc.

On Thursday, 1 August 2013 at 17:46:07 UTC, Gary Willoughby wrote:
> There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.

You do know that you can use GDC with rdmd? `rdmd --compiler=gdmd` afair.

Anyway, rdmd does it my checking dmd verbose output that lists all imports, as well as most other D build systems I am aware of.

On Thursday, 1 August 2013 at 19:06:38 UTC, Dicebot wrote:
> On Thursday, 1 August 2013 at 17:46:07 UTC, Gary Willoughby wrote:
>> There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.
>
> You do know that you can use GDC with rdmd? `rdmd --compiler=gdmd` afair.
>
> Anyway, rdmd does it my checking dmd verbose output that lists all imports, as well as most other D build systems I am aware of.

Ah good spot! I've compiled against GDC 4.8 and run into errors. It seems shellExecute from std.process is missing in GDC. How far behind is GDC? and does anyone know when this will be added?

On Fri, Aug 02, 2013 at 10:58:28AM +0200, Gary Willoughby wrote:
> On Thursday, 1 August 2013 at 19:06:38 UTC, Dicebot wrote:
> >On Thursday, 1 August 2013 at 17:46:07 UTC, Gary Willoughby wrote:
> >>There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.
> >
> >You do know that you can use GDC with rdmd? `rdmd --compiler=gdmd` afair.
> >
> >Anyway, rdmd does it my checking dmd verbose output that lists all imports, as well as most other D build systems I am aware of.
> 
> Ah good spot! I've compiled against GDC 4.8 and run into errors. It seems shellExecute from std.process is missing in GDC. How far behind is GDC? and does anyone know when this will be added?

What version of GDC are you using?


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth

On Friday, 2 August 2013 at 14:28:39 UTC, H. S. Teoh wrote:
> What version of GDC are you using?
>
>
> T

~ gdc -v
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)

On Fri, Aug 02, 2013 at 07:35:51PM +0200, Gary Willoughby wrote:
> On Friday, 2 August 2013 at 14:28:39 UTC, H. S. Teoh wrote:
> >What version of GDC are you using?
> >
> >
> >T
> 
> ~ gdc -v
[...]
> gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)

Heh, I'm using 4.8.1 too. And I just noticed shellExecute isn't available in my installation of GDC either. :-(


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright

On 08/01/2013 07:46 PM, Gary Willoughby wrote:
> There must be a simpler way to pass these files to dmd in the right order? rdmd does it somehow.
> 
> Any ideas? How do you handle compiling projects with 50+ source files?

This is a Makefile pattern I've found useful: https://github.com/WebDrake/Dgraph/blob/cache/Makefile

You have:

   DC -- D compiler, so you can replace with an arbitrary choice.  By habit I
         always use the DMD-like interfaces of compilers (so, gdmd and not gdc,
         ldmd2 and not ldc2), but you don't need to do that.

   DFLAGS -- compiler flags to use.

   LIBSRC -- list of source files.  You can see how I just use *.d to bring in
             everything.  This is fine in many circumstances.

   PROGS -- list of executables to build.

   all: $(PROGS) -- tells make that by default, it should build all the
                    programs.

   %: %.d $(LIBSRC)
       	$(DC) $(DFLAGS) -of$* $*.d $(LIBSRC)

       -- this basically uses a placeholder % that says: if you get issued a
          command, "make foo", then look for foo.d and build it together with
          the library sources to output the executable foo.

          It's a useful pattern because it means (i) if you add an extra program
          to the list of PROGS you don't have to update the Makefile anywhere
          else and (ii) you can create an arbitrary test file "bar.d" and then
          "make bar", and it'll build, even though it's not listed in PROGS.
            This means you can create and build local exploratory test programs
          which don't need to be added to the repo and for which you don't need
          to carry a local delta in your Makefile.

Whether that works for your 50+ file project will probably depend on how it's organized.  As others have said, you may want to look into a more sophisticated build system, and doing so is going to be helpful in any case.

Besides SCons and Tup, I've been recommended Waf and CMake.