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

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:

:import d   # imports the d specific routines
:program foo : foo.d  # compiles foo.obj, then links foo.exe
#:program {onestep} foo : foo.d  # this alternative will drop the
                                 # intermediate *.obj step

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

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

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

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

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