• Graham StJack (12/12) Sep 18 2003 As a new starter with D who has been using Ada and Java for a while, I
• Walter (7/19) Sep 18 2003 Great - you're in the right place.
• Helmut Leitner (13/32) Sep 19 2003 I'm with you. I think this is perhaps the "number one feature"
• John Boucher (14/46) Sep 19 2003 I'd think that would be fine with those 90-95% of cases. But I'd still u...
• Helmut Leitner (16/35) Sep 20 2003 Only the compiler can provide the information which modules have to be r...
• Benji Smith (29/34) Sep 22 2003 Very interesting. My opinion is exactly the opposite of this.
• Riccardo De Agostini (38/52) Sep 23 2003 Interesting, though maybe a little wordy... what if I don't have the sou...
• Felix (5/59) Sep 23 2003 As for resources compilation: the makefile isn't really necessarily. E.g...
• Riccardo De Agostini (24/28) Sep 24 2003 in
• Felix (7/37) Sep 24 2003 Sorry for mistake: yes, the BCB compiler does it right: compiles the res...
• Riccardo De Agostini (5/7) Sep 25 2003 behind

Graham StJack <grahams adpro.com.au> writes:

As a new starter with D who has been using Ada and Java for a while, I
must say I am really impressed with the language.

On dissapointment though, is the apparent lack of a built-in make facility.
What I mean is being able to type in something like: "dmd main_file_name"
and stand back while the compiler:

* uses the import statements and rules about packages vs directories
   to find all the files referred to

* compares timestamps to work out if a source file needs to be recompiled

* invokes the linker with all the right arguments

* hands me an executable on a silver platter


Both javac and gnatmake do this, and it is VERY easy to get used to.
Am I missing something - or is it back to "make" for me?

"Walter" <walter digitalmars.com> writes:

"Graham StJack" <grahams adpro.com.au> wrote in message
news:bkdt0e$1v63$1 digitaldaemon.com...
 As a new starter with D who has been using Ada and Java for a while, I
 must say I am really impressed with the language.

Great - you're in the right place.

 On dissapointment though, is the apparent lack of a built-in make

facility.
 What I mean is being able to type in something like: "dmd main_file_name"
 and stand back while the compiler:

 * uses the import statements and rules about packages vs directories
    to find all the files referred to

 * compares timestamps to work out if a source file needs to be recompiled

 * invokes the linker with all the right arguments

 * hands me an executable on a silver platter


 Both javac and gnatmake do this, and it is VERY easy to get used to.
 Am I missing something - or is it back to "make" for me?

The semantics of D make (!) it possible to do just that, however, the
compiler at the moment does not. Instead, a makefile is the way to go for
now. Such things will happen in the future.

Helmut Leitner <leitner hls.via.at> writes:

Graham StJack wrote:
 
 As a new starter with D who has been using Ada and Java for a while, I
 must say I am really impressed with the language.
 
 On dissapointment though, is the apparent lack of a built-in make facility.
 What I mean is being able to type in something like: "dmd main_file_name"
 and stand back while the compiler:
 
 * uses the import statements and rules about packages vs directories
    to find all the files referred to
 
 * compares timestamps to work out if a source file needs to be recompiled
 
 * invokes the linker with all the right arguments
 
 * hands me an executable on a silver platter
 
 Both javac and gnatmake do this, and it is VERY easy to get used to.
 Am I missing something - or is it back to "make" for me?

I'm with you. I think this is perhaps the "number one feature"
needed now, as common code projects gain momentum.

In fact, Burton Radon's DIGC goes a long way towards the goal. 
It currently works for modules in the main directory only, not down a tree.
But it does analyze dependencies and organizes the compile and link.
So perhaps 90-95% of what is needed should be in place.

I have looked into his code to extend it, but his DIG distribution lacks 
some common modules to build DIGC, so I stopped this. It's simpler to
wait until Burton turns up again. Some task must have swallowed him.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

John Boucher <John_member pathlink.com> writes:

In article <3F6AAF19.6898913D hls.via.at>, Helmut Leitner says...
Graham StJack wrote:
 
 As a new starter with D who has been using Ada and Java for a while, I
 must say I am really impressed with the language.
 
 On dissapointment though, is the apparent lack of a built-in make facility.
 What I mean is being able to type in something like: "dmd main_file_name"
 and stand back while the compiler:
 
 * uses the import statements and rules about packages vs directories
    to find all the files referred to
 
 * compares timestamps to work out if a source file needs to be recompiled
 
 * invokes the linker with all the right arguments
 
 * hands me an executable on a silver platter
 
 Both javac and gnatmake do this, and it is VERY easy to get used to.
 Am I missing something - or is it back to "make" for me?

I'm with you. I think this is perhaps the "number one feature"
needed now, as common code projects gain momentum.

In fact, Burton Radon's DIGC goes a long way towards the goal. 
It currently works for modules in the main directory only, not down a tree.
But it does analyze dependencies and organizes the compile and link.
So perhaps 90-95% of what is needed should be in place.

I have looked into his code to extend it, but his DIG distribution lacks 
some common modules to build DIGC, so I stopped this. It's simpler to
wait until Burton turns up again. Some task must have swallowed him.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

I'd think that would be fine with those 90-95% of cases. But I'd still use make
for trickier builds -- I really wouldn't want to bulk up the compiler with the
ability to find and access modules that are, perhaps, on the Web somewhere and
such.

My feeling is that the compiler should compile and very little else -- having it
automatically call the linker is fine, but that's about it. Any other functions
should be handled by the developer's choice of tools -- hopefully with a _large_
degree of standardization among the several development houses, however, such
should not be forced.

Uh, in case I haven't made it clear -- this is a reiteration of my dislike of
the compiler finding and processing D code within HTML files.

John Boucher
The King had Humpty pushed.

Helmut Leitner <leitner hls.via.at> writes:

John Boucher wrote:
I'm with you. I think this is perhaps the "number one feature"
needed now, as common code projects gain momentum.

In fact, Burton Radon's DIGC goes a long way towards the goal.
It currently works for modules in the main directory only, not down a tree.
But it does analyze dependencies and organizes the compile and link.
So perhaps 90-95% of what is needed should be in place.
 ...

 
 I'd think that would be fine with those 90-95% of cases. But I'd still use make
 for trickier builds -- I really wouldn't want to bulk up the compiler with the
 ability to find and access modules that are, perhaps, on the Web somewhere and
 such.
 
 My feeling is that the compiler should compile and very little else -- having
it
 automatically call the linker is fine, but that's about it. Any other functions
 should be handled by the developer's choice of tools -- hopefully with a
_large_
 degree of standardization among the several development houses, however, such
 should not be forced.

Only the compiler can provide the information which modules have to be
recompiled
because their objects are outdated. He can give this information to the make but
this leeds to a lengthy and inefficient turnaround. There is no need to make
this
the only way to make a project. One could add a compiler option to create a
separate
file containing a module list containing all dependencies that make can use.

make is perhaps everything, but not fast.

If the compiler builds an dependency tree and checks and compiles the necessary
sources, then we would get rid of library and makefile handling. I think this
would give us a large speed advantage in common code projects.

It would also help to create all types of tools and testfiles easily. No build
or make instruction except for special cases. Just update the necessary sources
to the unified d source tree and "dmd xyz_main.d". 

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Benji Smith <dlanguage xxagg.com> writes:

On Fri, 19 Sep 2003 17:58:47 +0000 (UTC), John Boucher
<John_member pathlink.com> wrote:

My feeling is that the compiler should compile and very little else -- having it
automatically call the linker is fine, but that's about it. Any other functions
should be handled by the developer's choice of tools -- hopefully with a _large_
degree of standardization among the several development houses, however, such
should not be forced.


Very interesting. My opinion is exactly the opposite of this.

From where I stand, tools like make and ant and such simply exist
becuase of defficiencies in the language and/or compiler. If my source
code has a statement like this:

import mylibrary;

...the compiler should know whether it's importing from a source file
or from a pre-compiled library. It should also know whether the
imported module should be statically linked into the executable or
whether it should be dynamically linked in some way. If the compiler
doesn't know what to do, then the import statement doesn't contain
enough information.

In my opinion, import statements should look more like this:

import as static from source d.digitalmars.phobos;
import as static from library d.burtonradeons.dig.*;
import as dll from source d.benjismith.spinnerette.xml;
import as dll from library d.benjismith.superduperwhammy;

I should also be able to put import statements inside of version
blocks (can we do that already?) so that I can control the compilation
parameters via versioning information.

Once all the code is written, I want to simply call the compiler,
using the name of the source file that contains the main method, like
this:

dmd myApp.d

So, in short, anything you can do with a makefile ought to be possible
using just your source code and a compiler.

Of course, I'm no expert with make, so that might be a really stupid
suggestion.

"Riccardo De Agostini" <riccardo.de.agostini email.it> writes:

"Benji Smith" <dlanguage xxagg.com> ha scritto nel messaggio
news:f40umvcgkvug9mi69b4jlrnjtgmbl1t1vn 4ax.com...

 In my opinion, import statements should look more like this:

 import as static from source d.digitalmars.phobos;
 import as static from library d.burtonradeons.dig.*;
 import as dll from source d.benjismith.spinnerette.xml;
 import as dll from library d.benjismith.superduperwhammy;

Interesting, though maybe a little wordy... what if I don't have the source
to Spinnerette, butjust the library? Should I change all the import
statements? How about good old library search paths, and if there's no
compiled library (or it's older than the source) automatic compilation?

 I should also be able to put import statements inside of version
 blocks (can we do that already?) so that I can control the compilation
 parameters via versioning information.

Of course. Version 2 of an app could use different libraries than version 1.

 Once all the code is written, I want to simply call the compiler,
 using the name of the source file that contains the main method, like
 this:

 dmd myApp.d

Agreed, absolutely. It may imply adding a keyword similar to Delphi's
"program" and "library", as opposed to "module" (which Delphi calls "unit").

======================
program MyApp;
// So the compiler knows it has to generate
// an executable, as opposed to a library

// These imports will probably be
// in the modules that actually use them
import d.digitalmars.phobos;
import d.burtonradeons.dig.*;
import d.benjismith.spinnerette.xml;
import d.benjismith.superduperwhammy;

import mymodule1; // These two are part
import mymodule2; // of the app itself

// Main function follows

======================
library d.benjismith.superduperwhammy; // ;-)

import this;
import that;
import whatever;

// No main, obviously

======================

 So, in short, anything you can do with a makefile ought to be possible
 using just your source code and a compiler.

Make can do more than that. For instance, you can use make to invoke a
program which converts graphical resources (or nationalized strings, or
whatever) into source that later gets compiled and linked in your program.
Every time you modify the resource or string file, make can automatically
convert it and recompile.

This, of course, does not imply that _having_ to use makefiles is right. I
am against the compile-link-keep_makefile_up_to_date_when_I_change_imports
thing altogether.

Ric

Felix <Felix_member pathlink.com> writes:

As for resources compilation: the makefile isn't really necessarily. E.g. in
Borland C++ Builder, the source file uses

#pragma resource xxx.res

to tell compiler to call the resource compiler.



In article <bkoup1$2csc$1 digitaldaemon.com>, Riccardo De Agostini says...
"Benji Smith" <dlanguage xxagg.com> ha scritto nel messaggio
news:f40umvcgkvug9mi69b4jlrnjtgmbl1t1vn 4ax.com...

 In my opinion, import statements should look more like this:

 import as static from source d.digitalmars.phobos;
 import as static from library d.burtonradeons.dig.*;
 import as dll from source d.benjismith.spinnerette.xml;
 import as dll from library d.benjismith.superduperwhammy;

Interesting, though maybe a little wordy... what if I don't have the source
to Spinnerette, butjust the library? Should I change all the import
statements? How about good old library search paths, and if there's no
compiled library (or it's older than the source) automatic compilation?

 I should also be able to put import statements inside of version
 blocks (can we do that already?) so that I can control the compilation
 parameters via versioning information.

Of course. Version 2 of an app could use different libraries than version 1.

 Once all the code is written, I want to simply call the compiler,
 using the name of the source file that contains the main method, like
 this:

 dmd myApp.d

Agreed, absolutely. It may imply adding a keyword similar to Delphi's
"program" and "library", as opposed to "module" (which Delphi calls "unit").

======================
program MyApp;
// So the compiler knows it has to generate
// an executable, as opposed to a library

// These imports will probably be
// in the modules that actually use them
import d.digitalmars.phobos;
import d.burtonradeons.dig.*;
import d.benjismith.spinnerette.xml;
import d.benjismith.superduperwhammy;

import mymodule1; // These two are part
import mymodule2; // of the app itself

// Main function follows

======================
library d.benjismith.superduperwhammy; // ;-)

import this;
import that;
import whatever;

// No main, obviously

======================

 So, in short, anything you can do with a makefile ought to be possible
 using just your source code and a compiler.

Make can do more than that. For instance, you can use make to invoke a
program which converts graphical resources (or nationalized strings, or
whatever) into source that later gets compiled and linked in your program.
Every time you modify the resource or string file, make can automatically
convert it and recompile.

This, of course, does not imply that _having_ to use makefiles is right. I
am against the compile-link-keep_makefile_up_to_date_when_I_change_imports
thing altogether.

Ric

"Riccardo De Agostini" <riccardo.de.agostini email.it> writes:

"Felix" <Felix_member pathlink.com> ha scritto nel messaggio
news:bkp1qp$2gpk$1 digitaldaemon.com...
 As for resources compilation: the makefile isn't really necessarily. E.g.

in
 Borland C++ Builder, the source file uses

 #pragma resource xxx.res

 to tell compiler to call the resource compiler.

If you define resources via a .RC file, will BC++ invoke the resource
compiler to generate the .RES from the .RC if the latter is newer?

Anyway, you could have resources which are stored in a non-standard way
(e.g. a .CSV file, with a message for each row and a language for each
column) and a custom app to extract data in a compilable or linkable format
(e.g. take a column from the CSV file and generate a C source containing the
messages as global string constants). Make would help in a case like this.

This brings me back to 1993, when I developed apps for an embedded "smart
terminal" with no OS at all, just a (poorly-written) multithreading kernel
running on a Motorola 68000. Tired of writing C code to draw graphics
screens (plant synoptics made up of hundreds of "moveto", "lineto",
"circle", etc. and to test 'em I had to burn an EPROM each time!) I wrote a
program to convert Adobe Illustrator 88 files (which I exported from
CorelDRAW) into 68k assembler sources. Every time I re-exported a screen,
make would re-convert, re-compile, re-link and, if just the EPROM programmer
were connected to my development PC, even re-burn if told so. :-)

So I think there are practical uses for make. Of course I don't like to
_have_ to use it for apps made up by a dozen of modules and two third-party
libraries, something the compiler should be able to handle itself, as Benji
stated.

Ric

Felix <Felix_member pathlink.com> writes:

Sorry for mistake: yes, the BCB compiler does it right: compiles the resources
if they are not compiled. Practically, it is possible to contruct a mekefile,
but this is not important. The fact that the compiler is the only one who
receives the file information still stands (and only the main app file).
And, +: no matter if the BCB does it, it is important that the ideea behind
works. different implem. is welcomed, no?


In article <bkrne5$5qm$1 digitaldaemon.com>, Riccardo De Agostini says...
"Felix" <Felix_member pathlink.com> ha scritto nel messaggio
news:bkp1qp$2gpk$1 digitaldaemon.com...
 As for resources compilation: the makefile isn't really necessarily. E.g.

in
 Borland C++ Builder, the source file uses

 #pragma resource xxx.res

 to tell compiler to call the resource compiler.

If you define resources via a .RC file, will BC++ invoke the resource
compiler to generate the .RES from the .RC if the latter is newer?

Anyway, you could have resources which are stored in a non-standard way
(e.g. a .CSV file, with a message for each row and a language for each
column) and a custom app to extract data in a compilable or linkable format
(e.g. take a column from the CSV file and generate a C source containing the
messages as global string constants). Make would help in a case like this.

This brings me back to 1993, when I developed apps for an embedded "smart
terminal" with no OS at all, just a (poorly-written) multithreading kernel
running on a Motorola 68000. Tired of writing C code to draw graphics
screens (plant synoptics made up of hundreds of "moveto", "lineto",
"circle", etc. and to test 'em I had to burn an EPROM each time!) I wrote a
program to convert Adobe Illustrator 88 files (which I exported from
CorelDRAW) into 68k assembler sources. Every time I re-exported a screen,
make would re-convert, re-compile, re-link and, if just the EPROM programmer
were connected to my development PC, even re-burn if told so. :-)

So I think there are practical uses for make. Of course I don't like to
_have_ to use it for apps made up by a dozen of modules and two third-party
libraries, something the compiler should be able to handle itself, as Benji
stated.

Ric

"Riccardo De Agostini" <riccardo.de.agostini email.it> writes:

"Felix" <Felix_member pathlink.com> ha scritto nel messaggio
news:bkrvn2$gem$1 digitaldaemon.com...
 And, +: no matter if the BCB does it, it is important that the ideea

behind
 works. different implem. is welcomed, no?

Of course. :-)

Ric