www.digitalmars.com         C & C++   DMDScript  

D - Make for D

reply 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?
Sep 18 2003
next sibling parent "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

 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.
Sep 18 2003
prev sibling parent reply 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
Sep 19 2003
parent reply 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.
Sep 19 2003
next sibling parent 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
Sep 20 2003
prev sibling parent reply 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.
Sep 22 2003
parent reply "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
Sep 23 2003
parent reply 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

Sep 23 2003
parent reply "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.

 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
Sep 24 2003
parent reply 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.

 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

Sep 24 2003
parent "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

 works. different implem. is welcomed, no?

Of course. :-) Ric
Sep 25 2003