August 24, 2004
After rereading your proposal somewhat more, I think that my ddepcheck could help you with much of the work (the dependency checking). Setting it up to find all recursively should be a nobrainer (actually, using the --checkprivate switch should do the trick).

You can find the last version at
http://www.igesund.net/larsivar/ddepcheck.d

Another project from me that has been little tested (AFAIK), btw.

Lars Ivar Igesund

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?
> 
August 24, 2004
>How much enthusiasm would you have for such a tool?

Alot, if you could get it to work ;).  Might also check out Lars' dep checker. Charlie

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).
>
>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


August 24, 2004
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 ...]

Sounds like a great idea!

How would it know which libraries would be needed? (I'm thinking of the
challenge of linking with system dlls such as shell32.lib, kernel32.lib,
gdi32.lib, etc.)

Do we need a Predefined Pragma, such as
  pragma(link, "gdi32");

http://www.digitalmars.com/d/pragma.html

Then the compiler-writer can ignore the info if he wishes, but there's
still a standarized way to do this.

(from http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8792)

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

I think I'm in favor of what you're suggesting, but I think it could be hard to persuade library writers to follow a convention. It seems like every project is set up quite differently than every other project. Phobos is even located in a special directory (\dmd\src\phobos\) rather than \dmd\src\!

Also, if someone is working on a project stored in a SVN repository (i.e. dsource.org), I think it'll be cumbersome to store it in \dmd\src\. We'd still need a way to provide include paths for the SVN cases.

Since variety is the spice of life (or something like that), here's some include paths for some various dsource projects:

claytek:  -I[claytek]\trunk\src\
core32:   -I[core32]\trunk\core32\
deimos:   -I[deimos]\trunk\
derelict: -I[derelict]trunk\DerelictSDL\
digdug:   -I[digdug]\
dwt:      -I[dwt]\trunk\src\
l8night:  -I[l8night]\trunk\l8night\
mango:    -I[mango]\trunk\
undig:    -I[undig]\trunk\

So "-[project]\trunk" is the winner with 3 votes? Not a very strong consensus.


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

I worked a little on making a simple build automation tool (with configuration options stored in the D source file), but I got bogged down by details and it never went anywhere.

> 
> What additional aspects, ideas, needs or problems come into your mind?
> 
> How much enthusiasm would you have for such a tool?

Count me as enthusiastic! :)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 25, 2004
I like the idea of this kind of tool.  The trouble with Scons and AAP is that they depend on the installation of python interpreter; I don't particularly care for that requirement.  Having a single independent tool like dmdmake is a neat and tidy solution.
August 25, 2004

J C Calvarese wrote:
> 
> 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 ...]
> 
> Sounds like a great idea!
> 
> How would it know which libraries would be needed? (I'm thinking of the challenge of linking with system dlls such as shell32.lib, kernel32.lib, gdi32.lib, etc.)
> 
> Do we need a Predefined Pragma, such as
>    pragma(link, "gdi32");

This would be nice sugar. But I thought about just passing the
library parameters to the compiler in the conventional way.

> http://www.digitalmars.com/d/pragma.html
> 
> Then the compiler-writer can ignore the info if he wishes, but there's still a standarized way to do this.
> 
> (from http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8792)
> 
> > 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.
> 
> I think I'm in favor of what you're suggesting, but I think it could be hard to persuade library writers to follow a convention. It seems like every project is set up quite differently than every other project. Phobos is even located in a special directory (\dmd\src\phobos\) rather than \dmd\src\!

There may be more than one source trees but it is easier if not
any project has its own. Unique module names are important to
avoid conflicts anyway (at least this was true with dmd 0.79).

> Also, if someone is working on a project stored in a SVN repository
> (i.e. dsource.org), I think it'll be cumbersome to store it in
> \dmd\src\. We'd still need a way to provide include paths for the SVN cases.
> 
> Since variety is the spice of life (or something like that), here's some include paths for some various dsource projects:
> 
> claytek:  -I[claytek]\trunk\src\
> core32:   -I[core32]\trunk\core32\
> deimos:   -I[deimos]\trunk\
> derelict: -I[derelict]trunk\DerelictSDL\
> digdug:   -I[digdug]\
> dwt:      -I[dwt]\trunk\src\
> l8night:  -I[l8night]\trunk\l8night\
> mango:    -I[mango]\trunk\
> undig:    -I[undig]\trunk\
> 
> So "-[project]\trunk" is the winner with 3 votes? Not a very strong consensus.
> 
> > Has anybody already thought about or built something like this?
> 
> I worked a little on making a simple build automation tool (with configuration options stored in the D source file), but I got bogged down by details and it never went anywhere.
> 
> >
> > What additional aspects, ideas, needs or problems come into your mind?
> >
> > How much enthusiasm would you have for such a tool?
> 
> Count me as enthusiastic! :)
> 
> --
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
August 26, 2004
I think Burton Radons' digc tool did something akin to this, as far as I know it hasn't been updated in a long time, but maybe you will find it useful:

http://www.opend.org/dig/arc/dig-0.0.14.zip

-Jon

Helmut Leitner wrote:
> 
> J C Calvarese wrote:
> 
>>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 ...]
>>
>>Sounds like a great idea!
>>
>>How would it know which libraries would be needed? (I'm thinking of the
>>challenge of linking with system dlls such as shell32.lib, kernel32.lib,
>>gdi32.lib, etc.)
>>
>>Do we need a Predefined Pragma, such as
>>   pragma(link, "gdi32");
> 
> 
> This would be nice sugar. But I thought about just passing the
> library parameters to the compiler in the conventional way.
>  
> 
>>http://www.digitalmars.com/d/pragma.html
>>
>>Then the compiler-writer can ignore the info if he wishes, but there's
>>still a standarized way to do this.
>>
>>(from http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8792)
>>
>>
>>>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.
>>
>>I think I'm in favor of what you're suggesting, but I think it could be
>>hard to persuade library writers to follow a convention. It seems like
>>every project is set up quite differently than every other project.
>>Phobos is even located in a special directory (\dmd\src\phobos\) rather
>>than \dmd\src\!
> 
> 
> There may be more than one source trees but it is easier if not
> any project has its own. Unique module names are important to
> avoid conflicts anyway (at least this was true with dmd 0.79).
>  
> 
>>Also, if someone is working on a project stored in a SVN repository
>>(i.e. dsource.org), I think it'll be cumbersome to store it in
>>\dmd\src\. We'd still need a way to provide include paths for the SVN cases.
>>
>>Since variety is the spice of life (or something like that), here's some
>>include paths for some various dsource projects:
>>
>>claytek:  -I[claytek]\trunk\src\
>>core32:   -I[core32]\trunk\core32\
>>deimos:   -I[deimos]\trunk\
>>derelict: -I[derelict]trunk\DerelictSDL\
>>digdug:   -I[digdug]\
>>dwt:      -I[dwt]\trunk\src\
>>l8night:  -I[l8night]\trunk\l8night\
>>mango:    -I[mango]\trunk\
>>undig:    -I[undig]\trunk\
>>
>>So "-[project]\trunk" is the winner with 3 votes? Not a very strong
>>consensus.
>>
>>
>>>Has anybody already thought about or built something like this?
>>
>>I worked a little on making a simple build automation tool (with
>>configuration options stored in the D source file), but I got bogged
>>down by details and it never went anywhere.
>>
>>
>>>What additional aspects, ideas, needs or problems come into your mind?
>>>
>>>How much enthusiasm would you have for such a tool?
>>
>>Count me as enthusiastic! :)
>>
>>--
>>Justin (a/k/a jcc7)
>>http://jcc_7.tripod.com/d/
> 
> 
August 26, 2004

Jon wrote:
> 
> I think Burton Radons' digc tool did something akin to this, as far as I know it hasn't been updated in a long time, but maybe you will find it useful:
> 
> http://www.opend.org/dig/arc/dig-0.0.14.zip
> 
> -Jon

Sorry for not mentioning that I took digc as a starting point for the dmdmake spike.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
August 26, 2004
Jon wrote:
> I think Burton Radons' digc tool did something akin to this, as far as I know it hasn't been updated in a long time, but maybe you will find it useful:
> 
> http://www.opend.org/dig/arc/dig-0.0.14.zip

By the way, the unDig project at dsource is attempt to keep dig living on. We try, but I just realized this week that parts of unDig have stopped running. I think everything compiles, but most of the examples have runtime errors. Oops.

http://www.dsource.org/projects/undig/

> 
> -Jon

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 26, 2004
J C Calvarese schrieb:
> By the way, the unDig project at dsource is attempt to keep dig living on. We try, but I just realized this week that parts of unDig have stopped running. I think everything compiles, but most of the examples have runtime errors. Oops.
> 
> http://www.dsource.org/projects/undig/

Uh, really? It didn't compile because it uses old casts all over the place, and besides its own windows module conflicts somewhat with the one from Phobos.

I moved it into another namespace and corrected the syntax, and now it bugs. But i didn't upload it there, because i don't think i was careful enough so i don't want to take responsibility. I shall send you my version by email.

-eye
August 26, 2004
In article <cgkvi3$ean$1@digitaldaemon.com>, Ilya Minkov says...
>
>J C Calvarese schrieb:
>> By the way, the unDig project at dsource is attempt to keep dig living on. We try, but I just realized this week that parts of unDig have stopped running. I think everything compiles, but most of the examples have runtime errors. Oops.
>> 
>> http://www.dsource.org/projects/undig/
>
>Uh, really? It didn't compile because it uses old casts all over the place, and besides its own windows module conflicts somewhat with the one from Phobos.

Sorry if I was unclear, but I don't think we're quite talking about the same thing. But I do appreciate any help you can give us.

I was talking about trying to compile and running the latest version of undig stored in the SVN repository. You might be talking about either http://svn.dsource.org/svn/projects/undig/downloads/undig.zip which I don't think has been updated in a few months or you might be using http://www.opend.org/dig/arc/dig-0.0.14.zip which is even older, but it worked great with the D compiler from back then.

In any case, it sounds like you know what you're doing, and I'd like to see what you did.

>
>I moved it into another namespace and corrected the syntax, and now it bugs. But i didn't upload it there, because i don't think i was careful enough so i don't want to take responsibility. I shall send you my version by email.

Yes, please send me your version (call me reckless, but I use an actual e-mail address here). Whatever you've done, I'd love to see it.

Just so that I understand better, did you actually get it to compile and the examples to run? That'd terrific! Or just compile? (Which is still good.) Compilation crashed due to a compiler bug? (I heard a rumor that happened recently, but I haven't seen it myself with unDig.)

(So many things can go wrong when compiling a big library that it seems like a miracle that it ever goes smoothly.)

>
>-eye

jcc7