A long time ago I did a development spike to simplify the build/make process of the D projects I experimented with at that time (before my timeout).

The idea was simple: write a tool dmdmake that
   - knows how to interpret import statements
   - asks dmd to compile and link all necessary sources

So instead of handling clumsy systems of
   - makefiles and
   - libraries

one could just write:

   dmdmake main.d [...options, but no other D-files mentioned ...]

and dmdmake would
   - recursively gather all import file dependencies
   - look which sources have to be recompiled acording to dependencies
   - call dmd to do the actual compile and link work

I did a spike and it basically worked, but I took some shortcuts
(e.g. ignoring "version", problems with multiple source trees),
so there is still work left to make it useful in real life.
And of course it was written in dmd 0.79 IIRC.

There was also a problem with Windows dmd which had to be called
multiple times because of the short command line. I intended to
talk Walter into providing an option to dmd to let one pass additional
parameters using stdin, which would simplify the process and
increase speed with Windows (work with a single dmd call).

I think working with a unified source tree without caring about project and library borders is much more fun and it would ease collaboration and give a push to D project development in general.

Has anybody already thought about or built something like this?

What additional aspects, ideas, needs or problems come into your mind?

How much enthusiasm would you have for such a tool?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> Has anybody already thought about or built something like this?
> 
AAP ( http://www.a-a-p.org/ ) supports D, but it was a bit rough around the edges when I last tried it (which was some time ago). I'm not sure if SCons ( http://www.scons.org/ ) supports D, too. I like the latter a bit better (no rhyme intended ;) ). Even if it doesn't, it should be easy to extend.
> How much enthusiasm would you have for such a tool?
> 

I like SCons. :)

IMHO it would be more useful to expand an existing tool. Being able to use a tool they already know (not that SCons has a big userbase, though) will ease the transition to D.

-Sebastian

Sebastian Beschke wrote:
> 
> Helmut Leitner wrote:
> > Has anybody already thought about or built something like this?
> >
> AAP ( http://www.a-a-p.org/ ) supports D, but it was a bit rough around
> the edges when I last tried it (which was some time ago). I'm not sure
> if SCons ( http://www.scons.org/ ) supports D, too. I like the latter a
> bit better (no rhyme intended ;) ). Even if it doesn't, it should be
> easy to extend.
> > How much enthusiasm would you have for such a tool?
> >
> 
> I like SCons. :)
> 
> IMHO it would be more useful to expand an existing tool. Being able to use a tool they already know (not that SCons has a big userbase, though) will ease the transition to D.
> 
> -Sebastian

I'm thankful for the hint to AAP (the scons link doesn't work for me) which may be useful for some other projects of mine.

The point is that dmdmake would be a make without a makefile. Not an improved makefile syntax, but no makefile syntax.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:

> A long time ago I did a development spike to simplify the build/make process of the D projects I experimented with at that time (before my timeout).
> 
> The idea was simple: write a tool dmdmake that
>    - knows how to interpret import statements
>    - asks dmd to compile and link all necessary sources
> 
> So instead of handling clumsy systems of
>    - makefiles and
>    - libraries
> 
> one could just write:
> 
>    dmdmake main.d [...options, but no other D-files mentioned ...]
> 
> and dmdmake would
>    - recursively gather all import file dependencies
>    - look which sources have to be recompiled acording to dependencies
>    - call dmd to do the actual compile and link work
> 
> I did a spike and it basically worked, but I took some shortcuts
> (e.g. ignoring "version", problems with multiple source trees),
> so there is still work left to make it useful in real life.
> And of course it was written in dmd 0.79 IIRC.
> 
> There was also a problem with Windows dmd which had to be called
> multiple times because of the short command line. I intended to
> talk Walter into providing an option to dmd to let one pass additional
> parameters using stdin, which would simplify the process and
> increase speed with Windows (work with a single dmd call).
> 
> I think working with a unified source tree without caring about project and library borders is much more fun and it would ease collaboration and give a push to D project development in general.
> 
> Has anybody already thought about or built something like this?
> 
> What additional aspects, ideas, needs or problems come into your mind?
> 
> How much enthusiasm would you have for such a tool?
> 

Sounds cool. I'd love it. All my D makefiles are boring list of dependencies just like you've described. It would be great to toss them out.

In article <412B13EB.19EAB285@hls.via.at>, Helmut Leitner says...

>Has anybody already thought about or built something like this?

Yes, I have a PHP script which does exactly that. Plus, it can handle versions, and know when to link with certain libraries.

Jill

Helmut Leitner wrote:
> A long time ago I did a development spike to simplify the build/make process of the D projects I experimented with at that time (before my timeout).
> 
> The idea was simple: write a tool dmdmake that    - knows how to interpret import statements
>    - asks dmd to compile and link all necessary sources
> 
> So instead of handling clumsy systems of    - makefiles and    - libraries
> 
> one could just write:
> 
>    dmdmake main.d [...options, but no other D-files mentioned ...]
> 
> and dmdmake would    - recursively gather all import file dependencies    - look which sources have to be recompiled acording to dependencies
>    - call dmd to do the actual compile and link work
> 
> I did a spike and it basically worked, but I took some shortcuts
> (e.g. ignoring "version", problems with multiple source trees),
> so there is still work left to make it useful in real life.
> And of course it was written in dmd 0.79 IIRC.
> 
> There was also a problem with Windows dmd which had to be called
> multiple times because of the short command line. I intended to
> talk Walter into providing an option to dmd to let one pass additional
> parameters using stdin, which would simplify the process and increase speed with Windows (work with a single dmd call).
> 
> I think working with a unified source tree without caring about project and library borders is much more fun and it would ease collaboration and give a push to D project development in general.
> 
> Has anybody already thought about or built something like this?
Not me.
> 
> What additional aspects, ideas, needs or problems come into your mind?
> 
Someone might want to compile a library without a main. Though you could always have dmdmake --lib lib.d, which would produce a lib.lib on windows and liblib.a on linux.

I like the idea of calling dmdmake on a main program however as it would  compile the program with multiple libraries without a makefile.

Would or could you specify the obj/ src/ lib/ bin/ directories with dmdmake like you could with dmd?

Also, would it not be a bad idea to have this as a build option for dmd? like 'dmd --make file.d -Isrc/ -odobj/ -ofbin/ -v etc.'

> How much enthusiasm would you have for such a tool?
> 
A bunch. I know I spend a lot of time tweaking my makefiles.

In article <412B13EB.19EAB285@hls.via.at>, Helmut Leitner says...
>
>A long time ago I did a development spike to simplify the build/make process of the D projects I experimented with at that time (before my timeout).

Please excuse my ignorance if you've posted it before, but is this online anywhere?  I'd like to have something like this as I loathe 'make', and would prefer not to install python (for scons).

>There was also a problem with Windows dmd which had to be called
>multiple times because of the short command line. I intended to
>talk Walter into providing an option to dmd to let one pass additional
>parameters using stdin, which would simplify the process and
>increase speed with Windows (work with a single dmd call).

All of Digitalmars' tools (make, dmd, dmc, optlink) accept a "response file" by using "@filename" in the command line:

e.g. dmd @cmdline.txt

>I think working with a unified source tree without caring about project and library borders is much more fun and it would ease collaboration and give a push to D project development in general.
>
>Has anybody already thought about or built something like this?
>
>What additional aspects, ideas, needs or problems come into your mind?

Ever tried to herd cats before? :)

Synicism aside, I think it'd be interesting to see a "superproject" on dsource (or somewhere else) that attempts to create a distribution of all of the other aggregate projects out there (that's all, no additional source work, just a binary and source distro for easy programming).  I think that'd be about as close as you could get to a "unified" source tree outside of std phobos, as everything is so independent.

Now if there was a standard for achieving a "Seal of Quality" or "Official D Library" labeling for a project, that would be very different and could help establish some kind of unification. ;)

>
>How much enthusiasm would you have for such a tool?

If it cuts down the time it takes to go from "I need lib Y on site X" to "I'm compiling lib Y it into my project" it's going to be very useful IMO.

- Pragma

Helmut Leitner wrote:

> 
> I'm thankful for the hint to AAP (the scons link doesn't work for me)
> which may be useful for some other projects of mine.

I'm the man behind the D support in A-A-P. My local copy of it works very well for me, but it has been little tested by others and my last patches hasn't been included AFAIK (Bram Molenaar hasn't been present on the developers list lately.)

Mail me or the list if you have any problems.

Lars Ivar Igesund

Sebastian Beschke wrote:
> Helmut Leitner wrote:
> 
>> Has anybody already thought about or built something like this?
>>
> AAP ( http://www.a-a-p.org/ ) supports D, but it was a bit rough around the edges when I last tried it (which was some time ago). I'm not sure if SCons ( http://www.scons.org/ ) supports D, too. I like the latter a bit better (no rhyme intended ;) ). Even if it doesn't, it should be easy to extend.
> 
>> How much enthusiasm would you have for such a tool?
>>
> 
> I like SCons. :)
> 
> IMHO it would be more useful to expand an existing tool. Being able to use a tool they already know (not that SCons has a big userbase, though) will ease the transition to D.

SCons supports D as of 0.95.  Its homepage seems to be down at the moment, but the sourceforge page is still up:

<http://sourceforge.net/projects/scons>

 -- andy

Arcane Jill wrote:
> 
> In article <412B13EB.19EAB285@hls.via.at>, Helmut Leitner says...
> 
> >Has anybody already thought about or built something like this?
> 
> Yes, I have a PHP script which does exactly that. Plus, it can handle versions, and know when to link with certain libraries.

Sorry, inevitable question: Would you share it with us?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com