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?
 


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


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


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


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