www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmdmake tool spike - please comment on idea

reply Helmut Leitner <leitner hls.via.at> writes:
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
Aug 24 2004
next sibling parent reply Sebastian Beschke <s.beschke gmx.de> writes:
Helmut Leitner wrote:
 Has anybody already thought about or built something like this?
 

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
Aug 24 2004
next sibling parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
Sebastian Beschke wrote:
 
 Helmut Leitner wrote:
 Has anybody already thought about or built something like this?

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
Aug 24 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Aug 24 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
Sebastian Beschke wrote:
 Helmut Leitner wrote:
 
 Has anybody already thought about or built something like this?

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
Aug 24 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
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.
Aug 24 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Aug 24 2004
parent Helmut Leitner <leitner hls.via.at> writes:
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
Aug 24 2004
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
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?
 

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?
 

Aug 24 2004
prev sibling next sibling parent pragma <EricAnderton at yahoo dot com> <pragma_member pathlink.com> writes:
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
Aug 24 2004
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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?
 

Aug 24 2004
prev sibling next sibling parent Charlie <Charlie_member pathlink.com> writes:
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

Aug 24 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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 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/
Aug 24 2004
parent reply Helmut Leitner <leitner hls.via.at> writes:
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 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
Aug 25 2004
parent reply Jon <s12 kron.cx> writes:
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 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/


Aug 25 2004
next sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
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
Aug 25 2004
parent Charlie <Charlie_member pathlink.com> writes:
One of the cool things of digc is omfListExports function, given an object file
it will create the nesccessary exports for DLL creation. I still haven't gotten
classes to work with DLL's ( anyone else ? ) , but I think eventually that would
be very cool, not having to decorate all my classes with 'export'.

Charlie

In article <412D8953.B23779D7 hls.via.at>, Helmut Leitner says...
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

Aug 26 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Aug 26 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Aug 26 2004
parent J C Calvarese <jcc7 cox.net> writes:
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
Aug 26 2004
prev sibling parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
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.
Aug 24 2004