www.digitalmars.com         C & C++   DMDScript  

D - a dmake program NOT needed

reply Ant <Ant_member pathlink.com> writes:
Ok guys I'm puzzeled by the other discussion with a
subject similar to this one.

the objective of make is to reduce build time by avoiding
rebuilding the objs that are up to date with the source.

this is not necessary with dmd! dmd is so fast that
is an absolute waist of time trying to create a make file.
(I hope that if you have an app with several million lines of
code you are smart enough to split it into smaller libs)

let me say this again (I said it twice or 2 times before):
gtkmm takes something like 1/2 hour
to compile and DUI (granted has only about half the lines)
takes less then 3 seconds plus the time to link.
DUI takes less time to compile then make for gtkmm takes to 
figure out that every thing is up to date!

also the suggestion that the import dependencies should be
computed and compiled forget to take into account that
library modules shouldn't be recompiled and also show on the
import declarations.
(probably a small fix on the process)

forget the dmake thing.

we do need the "private import" to really work.

leds approch (next release) is to compile every thing on
the source tree (first level dirs can be filtered and 
several targets can be set for each project)
that will work (tested already) as long as "private import"
is respected by dmd.
leds will also be able to generate a make file (tested already)
from the  targets definitions so that it can be fine tuned to
overcome the "private import" bug, not because a dmake is necessary.
(I'm just rewriting the targets definition UI so that each target
has it's own compiler options)
leds can be compiled that way, I didn't tested with DUI yet.

of course if I'm missing something please let me know.

Ant

http://leds.sourceforge.net
http://dui.sourceforge.net
Mar 25 2004
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ant wrote:


 Ok guys I'm puzzeled by the other discussion with a
 subject similar to this one.
 
 the objective of make is to reduce build time by avoiding
 rebuilding the objs that are up to date with the source.
 
 this is not necessary with dmd! dmd is so fast that
 is an absolute waist of time trying to create a make file.
 (I hope that if you have an app with several million lines of
 code you are smart enough to split it into smaller libs)
 
 let me say this again (I said it twice or 2 times before):
 gtkmm takes something like 1/2 hour
 to compile and DUI (granted has only about half the lines)
 takes less then 3 seconds plus the time to link.
 DUI takes less time to compile then make for gtkmm takes to 
 figure out that every thing is up to date!


I am well aware of this. Therefore it is quite possible to
turn off autodependencies in A-A-P. What A-A-P DOES do better
than make, is that it knows the exact commands for the most
usual things. This means that a single OPTIMIZE variable can
be set and it will work with all supported languages (and
compilers). The simplest A-A-P recipe possible (for D) is:






The drawback is that the support needs to implemented for
all tools.

And to Andy Friesen:
I think it is quite nice to NOT HAVE to use Python, as the A-A-P
syntax is both easier and more fit for such operations. :)

Lars Ivar Igesund
Mar 25 2004
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Ant schrieb:


 also the suggestion that the import dependencies should be
 computed and compiled forget to take into account that
 library modules shouldn't be recompiled and also show on the
 import declarations.
 (probably a small fix on the process)


But digc can already "install" libraries. If you use a library which is 
"installed", it is not compiled in, but simply linked in instead. Digc 
maintains the registry of installed libraries. So don't take or make any 
suggestions before having run digc, and all suggestions should be 
presented as already working modified versions of it. ;)

True, analysis of what should be recompiled and what not does not yuild 
almost anything in current setup, but it very well might with GCC where 
code generator might have strong breaks holding it? Not that i would 
know exactly. And all the files should be compiled at once anyway.

When setting up a project in a dedicated editor, it actually does not 
matter. But from command line just saying "digc main" is much more sweet 
than having to remember what other modules and libraries were used, 
including indirectly.

-eye
Mar 25 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
Ant wrote:


 of course if I'm missing something please let me know.


How about dealing with varying system configurations?  I don't care to 
write separate makefiles for every platform or to manually deal with 
every compiler. (this will become more important as gdc matures) 
automake and autoconf aren't very appealing options.

  -- andy
Mar 25 2004
prev sibling parent reply Olaf Rogalsky <rogalsky physik.uni-erlangen.de> writes:
Ant wrote:


 let me say this again (I said it twice or 2 times before):
 gtkmm takes something like 1/2 hour
 to compile and DUI (granted has only about half the lines)
 takes less then 3 seconds plus the time to link.
 DUI takes less time to compile then make for gtkmm takes to
 figure out that every thing is up to date!


Is this still true for the gnu d compiler, or any other 
compiler of the future? Is this really true for all build system 
implementations?

So long, Olaf


-- 
+-------------------------------------------------------------------+
I Dr. rer. nat. Olaf Rogalsky     Institut fuer Theoretische Physik I
I                                 Universitaet Erlangen-Nuernberg   I
I Tel.: 09131 8528440             Staudtstr. 7 B3                   I
I Fax.: 09131 8528444             D-91058 Erlangen                  I
| rogalsky theorie1.physik.uni-erlangen.de                          I
+-------------------------------------------------------------------+
Mar 26 2004
parent Ant <Ant_member pathlink.com> writes:
In article <406423CE.450BEF7C physik.uni-erlangen.de>, Olaf Rogalsky says...

Ant wrote:


 let me say this again (I said it twice or 2 times before):
 gtkmm takes something like 1/2 hour
 to compile and DUI (granted has only about half the lines)
 takes less then 3 seconds plus the time to link.
 DUI takes less time to compile then make for gtkmm takes to
 figure out that every thing is up to date!


Is this still true for the gnu d compiler, or any other 
compiler of the future? Is this really true for all build system 
implementations?

So long, Olaf


Probably not. you guys are right.
please continue the dmake discussion.

Ant
Mar 26 2004