www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mission: Makefile must die?

reply New Ape <New_member pathlink.com> writes:
Dear DigitalMars and United Unix,

Should we bother for Makefiles even on D?
The Makefile-related autotool programs are obsolete because of:

(a) wasting time and cost in heavy environment inspections and expensive dynamic
data genarations
(b) these cheap-looked user-interfaces
(c) these non-portable procedure-oriented data format that depends on uncommon
options of individual tools

Thanks,
Feb 10 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
New Ape wrote:
 Dear DigitalMars and United Unix,
 
 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:
 
 (a) wasting time and cost in heavy environment inspections and expensive
dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on uncommon
 options of individual tools
 
 Thanks,
 
 
Agreed. the makefile must die for D. :-)
Feb 10 2005
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
John Reimer wrote:
 New Ape wrote:
 
 Dear DigitalMars and United Unix,

 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:

 (a) wasting time and cost in heavy environment inspections and 
 expensive dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on 
 uncommon
 options of individual tools

 Thanks,
Agreed. the makefile must die for D. :-)
Would dmake be the replacement?
Feb 10 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
clayasaurus wrote:
 John Reimer wrote:
 
 New Ape wrote:

 Dear DigitalMars and United Unix,

 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:

 (a) wasting time and cost in heavy environment inspections and 
 expensive dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on 
 uncommon
 options of individual tools

 Thanks,
Agreed. the makefile must die for D. :-)
Would dmake be the replacement?
dmake or digc. Both need improvement before they can qualify (but they're close!). - John R.
Feb 10 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 The Makefile-related autotool programs are obsolete because of:
Agreed. the makefile must die for D. :-)
Would dmake be the replacement?
dmake or digc. Both need improvement before they can qualify (but they're close!).
Outside D world, dmake means "Distributed Make" Code might be good, but name needs to change... http://www.prowiki.org/wiki4d/wiki.cgi?Dmake --anders
Feb 11 2005
parent reply zwang <nehzgnaw gmail.com> writes:
Anders F Bj鰎klund wrote:
 
 Outside D world, dmake means "Distributed Make"
 
 Code might be good, but name needs to change...
 
 http://www.prowiki.org/wiki4d/wiki.cgi?Dmake
 
 --anders
How about "made"?
Feb 11 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"zwang" <nehzgnaw gmail.com> wrote in message 
news:cuhrq2$1cbn$1 digitaldaemon.com...
 Anders F Bj鰎klund wrote:
 Outside D world, dmake means "Distributed Make"

 Code might be good, but name needs to change...

 http://www.prowiki.org/wiki4d/wiki.cgi?Dmake

 --anders
How about "made"?
nice. Gets my vote :-)
Feb 11 2005
prev sibling parent "Charlie Patterson" <charliep1 excite.com> writes:
 Agreed. the makefile must die for D.   :-)
Would dmake be the replacement?
This is the first I've heard of this dmake. Is it tied to D's syntax or style? Or is it a different approach to make in general? If a new approach, my first suggestion would be to name is separate from D (*d*make) because a generally useful tool is always nice and you wouldn't want to get it clumped in to D if it is more.
Feb 11 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <cugtuh$avd$1 digitaldaemon.com>, John Reimer says...
New Ape wrote:
 Dear DigitalMars and United Unix,
 
 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:
 
 (a) wasting time and cost in heavy environment inspections and expensive
dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on uncommon
 options of individual tools
 
 Thanks,
 
 
Agreed. the makefile must die for D. :-)
Thank god someone started this thread. I can contribute dbuild, as it works to that end. However, it's still mostly broken and badly in need of improvment. DMake and Digc have also been suggested... perhaps we can all work toward a common protocol for tackling this problem? I'd like to see something open-ended enough to incorporate something like ddoc and other bits into the toolchain (like DMC for building C libs) without approaching Make's complexity (and hassle). Even if it means making a more complicated tool, I think it will be worth it in the end. - EricAnderton at yahoo
Feb 10 2005
parent John Reimer <brk_6502 yahoo.com> writes:
pragma wrote:
 
 Thank god someone started this thread.
 
 I can contribute dbuild, as it works to that end.  However, it's still mostly
 broken and badly in need of improvment.
 
 DMake and Digc have also been suggested... perhaps we can all work toward a
 common protocol for tackling this problem?
 
 I'd like to see something open-ended enough to incorporate something like ddoc
 and other bits into the toolchain (like DMC for building C libs) without
 approaching Make's complexity (and hassle).  Even if it means making a more
 complicated tool, I think it will be worth it in the end.
 
 - EricAnderton at yahoo
I agree! It's about time this topic was discussed in earnest. I remember you mentioning that you made a slew of changes for dbuild, although I never really looked into what you had done. You're right. We should pull Derek's build, Helmet's dmake, Burton's digc, and your dbuild all together and see what explosive concoction can be wrought. I think we should get a dsource.org project set up soon. Later, John R.
Feb 10 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 11 Feb 2005 00:14:10 +0000 (UTC), New Ape wrote:

 Dear DigitalMars and United Unix,
 
 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:
 
 (a) wasting time and cost in heavy environment inspections and expensive
dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on uncommon
 options of individual tools
 
 Thanks,
I am just about to release v1.0 of my Build utility. This has been based on the dmake program, but with lots of changes. I'm currently updating the documentation for it, and it all should be ready for review in about 24 hours. Currently, it can create an executable or a library (or neither) by just supplying it with the top level source code file name. It works out the dependencies and which files need compiling. It has support for identifying which libraries (if any) are needed by the linker by placing pragma statements in your source code ... version(build) pragma(link, MySuperLibrary); Once this version is out, I'll try to add DLL building support, and library maintenance (as opposed to creation) to the next version. -- Derek Melbourne, Australia 11/02/2005 2:57:06 PM
Feb 10 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:

 I am just about to release v1.0 of my Build utility. This has been based on
 the dmake program, but with lots of changes.
 
 I'm currently updating the documentation for it, and it all should be ready
 for review in about 24 hours.
 
 Currently, it can create an executable or a library (or neither) by just
 supplying it with the top level source code file name. It works out the
 dependencies and which files need compiling. It has support for identifying
 which libraries (if any) are needed by the linker by placing pragma
 statements in your source code ...
 
 version(build) pragma(link, MySuperLibrary);
 
 Once this version is out, I'll try to add DLL building support, and library
 maintenance (as opposed to creation) to the next version.
 
I was hoping you would post about your build utility. :-) Between "build" and "dbuild" by pragma, I think some super-tool can be worked out. A bunch of us should review these tools, fine tune some features, and discuss what further features should be supplied. Specifically a project needs to be started on dsource.org to get the ball rolling. Prior projects have been "proprietary", hidden away as special tools attatched to certain projects. We need get a build tool project out in the open. A few things we should be looking for in d build: 1) Support for dmd and gdc 2) Support for a minimum of Win32, Linux, and Darwin 3) Lib creation on all platforms 4) Consider dynamic library support on all platforms (sadly dmd can't do dlls for anything but win32 at present) 5) Stripping support built in for commercial projects (ala digc) I'm sure there's plenty more ideas to work out. We should be able to pull several techniques from different projects and combine them into one. This is a start. Later, John
Feb 10 2005
parent reply nail <nail_member pathlink.com> writes:
In article <cuhbql$mtm$1 digitaldaemon.com>, John Reimer says...
Derek Parnell wrote:

 I am just about to release v1.0 of my Build utility. This has been based on
 the dmake program, but with lots of changes.
 
 I'm currently updating the documentation for it, and it all should be ready
 for review in about 24 hours.
 
 Currently, it can create an executable or a library (or neither) by just
 supplying it with the top level source code file name. It works out the
 dependencies and which files need compiling. It has support for identifying
 which libraries (if any) are needed by the linker by placing pragma
 statements in your source code ...
 
 version(build) pragma(link, MySuperLibrary);
 
 Once this version is out, I'll try to add DLL building support, and library
 maintenance (as opposed to creation) to the next version.
 
I was hoping you would post about your build utility. :-) Between "build" and "dbuild" by pragma, I think some super-tool can be worked out. A bunch of us should review these tools, fine tune some features, and discuss what further features should be supplied. Specifically a project needs to be started on dsource.org to get the ball rolling. Prior projects have been "proprietary", hidden away as special tools attatched to certain projects. We need get a build tool project out in the open. A few things we should be looking for in d build: 1) Support for dmd and gdc 2) Support for a minimum of Win32, Linux, and Darwin 3) Lib creation on all platforms 4) Consider dynamic library support on all platforms (sadly dmd can't do dlls for anything but win32 at present) 5) Stripping support built in for commercial projects (ala digc)
SCons, scons, and one more time scons. Why to invent wheel twice? If your arguments will "scons usualy not avaible after os installation like make" or "scons uses python, not D" I'll disagree with you. It is unlikely dbuild will be initialy avaible in os distrib and what is the difference what scripts to use true python or new artificial? BTW if someone russian will read dbuild aloud the result will be "moron" in russian.
Feb 11 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
nail wrote:

 SCons, scons, and one more time scons. Why to invent wheel twice? 
Twice ? More like "toss another one to the mountain of Makes" ;-)
 If your arguments will "scons usualy not avaible after os installation like
make" or
 "scons uses python, not D" I'll disagree with you. It is unlikely dbuild will
be
 initialy avaible in os distrib and what is the difference what scripts to use
 true python or new artificial?
At least Scons worked right away, and you didn't *have* to look at the Python code unless doing something tricky. So it's good. I like Make, but cross-platform it is not (i.e. not for Windows) Also, it does have ready-made installers for all popular platforms. http://www.scons.org/doc/HTML/scons-user.html#CHAP-BUILD-INSTALL So I agree that just using Scons sounds better than "Dmake"... Can any Scons expert translate the Phobos and Mango makefiles, just so everyone can get a feel of what it would be like to use ? --anders
Feb 11 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
nail wrote:
 In article <cuhbql$mtm$1 digitaldaemon.com>, John Reimer says...
 
 
 SCons, scons, and one more time scons. Why to invent wheel twice? If your
 arguments will "scons usualy not avaible after os installation like make" or
 "scons uses python, not D" I'll disagree with you. It is unlikely dbuild will
be
 initialy avaible in os distrib and what is the difference what scripts to use
 true python or new artificial?
 
 BTW if someone russian will read dbuild aloud the result will be "moron" in
 russian.
 
 
I've heard of Scons. I've used Scons. I don't think much of Scons. It's a great little tool. But we need something unattatched to a scripting language. I can't see Scons having the performance or flexibility of an open d make tool designed for the d system. I think something made for d using the d language is a good solution. Go ahead and disagree; you're good at it. Here are a few reasons why scons doesn't cut it (in my opinion): 1) Scons uses python ;-) 2) Scons does not support D pragmas() or versions statements (or does it?) 3) Scons still needs a build file (something dbuild or dmake do not: they compile based on source alone) 4) Scons uses python commands in it's config file: there's no choice there; therefore the build format is not negotiable. 5) Scons is not a single entity/executable. It's dependency is the whole python system. Sure python has been ported almost everywhere; but for every platform that d can be ported to, a single d make tool is surely going to be portable too. I love "simple" things: one tool, one executable, no dependencies, fast operation, integration into d programs making the source itself the make script; pre-processor type directives are also possible here. 6) Scons isn't always simple to set up (especially because of it's dependencies). If your python is messed up for some reason, so is scons. A single dmake tool won't inherit that problem. 7) Scons has a learning curve, even if it is small compared to some tools. A dmake tool should be able to compile simple projects just by running it in the parent directory... practically no interaction for simple projects. You can learn more powerful features as you go. This is important for brand new users and new D programmers. Besides, what's wrong with starting another project? What is it to you? Is it that painful for you that other people might choose something else? I feel for you, man. All in good fun, nail. :-) - John R.
Feb 11 2005
parent reply nail <nail_member pathlink.com> writes:
In article <cuhsgq$1ef4$1 digitaldaemon.com>, John Reimer says...
nail wrote:
 In article <cuhbql$mtm$1 digitaldaemon.com>, John Reimer says...
 
 
 SCons, scons, and one more time scons. Why to invent wheel twice? If your
 arguments will "scons usualy not avaible after os installation like make" or
 "scons uses python, not D" I'll disagree with you. It is unlikely dbuild will
be
 initialy avaible in os distrib and what is the difference what scripts to use
 true python or new artificial?
 
 BTW if someone russian will read dbuild aloud the result will be "moron" in
 russian.
 
 
I've heard of Scons. I've used Scons. I don't think much of Scons. It's a great little tool. But we need something unattatched to a scripting language. I can't see Scons having the performance or flexibility of an open d make tool designed for the d system. I think something made for d using the d language is a good solution. Go ahead and disagree; you're good at it. Here are a few reasons why scons doesn't cut it (in my opinion): 1) Scons uses python ;-)
Haaa, haaa, haaa. And what? Looks like python is suitable only for building python scripts for python developers (lol, "building scripts":)
2) Scons does not support D pragmas() or versions statements (or does it?)
SCons support everything. The flexibility is enough to configure it for coffe cooking if blablabla.d is outdated.
3) Scons still needs a build file (something dbuild or dmake do not: 
they compile based on source alone)
Hm, and parameters? Will I have to write: dbuild --ignore-files="bla.d foo.d bar.d" --version=someversion --debug=5 --someoption=somevalue --somefoooption=somefoovalue --somebaroption=somebarvalue --somebazoption=somebazvalue --somemoreoption=somemorevalue --someoption=somevalue --someanotheroption=someanothervalue Great!
4) Scons uses python commands in it's config file: there's no choice 
there; therefore the build format is not negotiable.
How many different SConscripts I seen they all are totaly different. One build problem you can solve in veeeeeeeeery many ways using scons.
5) Scons is not a single entity/executable.

It's dependency is the whole python system.  Sure python has been ported 
almost everywhere; but for every platform that d can be ported to, a 
single d make tool is surely going to be portable too.  I love "simple" 
things: one tool, one executable, no dependencies, fast operation, 
integration into d programs making the source itself the make script; 
pre-processor type directives are also possible here.
scons+python can be one .zip :)
6) Scons isn't always simple to set up (especially because of it's 
dependencies).  If your python is messed up for some reason, so is 
scons.  A single dmake tool won't inherit that problem.
I'm full dummy in linux but I installed python + scons very simply, no problems like in other soft.
7) Scons has a learning curve, even if it is small compared to some 
tools.  A dmake tool should be able to compile simple projects just by 
running it in the parent directory... practically no interaction for 
simple projects.  You can learn more powerful features as you go.  This 
is important for brand new users and new D programmers.
This curve pass during hour of reading and 1-2 days of practice.
Besides, what's wrong with starting another project?  What is it to you? 
  Is it that painful for you that other people might choose something 
else?  I feel for you, man.
Ok I'm not against, but reading this thread I understand that dbuild would not revolutional tool, inside dcommunity people still will use make, scons, other tools furthermore they will be used oftenly than dbuild. That was just my IMHO. Victor Nakoryakov nail-mail<at> mail<dot>ru
Feb 11 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
nail wrote:
 In article <cuhsgq$1ef4$1 digitaldaemon.com>, John Reimer says...
 
nail wrote:

In article <cuhbql$mtm$1 digitaldaemon.com>, John Reimer says...


SCons, scons, and one more time scons. Why to invent wheel twice? If your
arguments will "scons usualy not avaible after os installation like make" or
"scons uses python, not D" I'll disagree with you. It is unlikely dbuild will be
initialy avaible in os distrib and what is the difference what scripts to use
true python or new artificial?

BTW if someone russian will read dbuild aloud the result will be "moron" in
russian.
I've heard of Scons. I've used Scons. I don't think much of Scons. It's a great little tool. But we need something unattatched to a scripting language. I can't see Scons having the performance or flexibility of an open d make tool designed for the d system. I think something made for d using the d language is a good solution. Go ahead and disagree; you're good at it. Here are a few reasons why scons doesn't cut it (in my opinion): 1) Scons uses python ;-)
Haaa, haaa, haaa. And what? Looks like python is suitable only for building python scripts for python developers (lol, "building scripts":)
2) Scons does not support D pragmas() or versions statements (or does it?)
SCons support everything. The flexibility is enough to configure it for coffe cooking if blablabla.d is outdated.
3) Scons still needs a build file (something dbuild or dmake do not: 
they compile based on source alone)
Hm, and parameters? Will I have to write: dbuild --ignore-files="bla.d foo.d bar.d" --version=someversion --debug=5 --someoption=somevalue --somefoooption=somefoovalue --somebaroption=somebarvalue --somebazoption=somebazvalue --somemoreoption=somemorevalue --someoption=somevalue --someanotheroption=someanothervalue Great!
*SIGH* What can I say, Victor; you're determined to think ill of the idea. Of course you'll think up such an unsightly exec.
 
4) Scons uses python commands in it's config file: there's no choice 
there; therefore the build format is not negotiable.
How many different SConscripts I seen they all are totaly different. One build problem you can solve in veeeeeeeeery many ways using scons.
5) Scons is not a single entity/executable.

It's dependency is the whole python system.  Sure python has been ported 
almost everywhere; but for every platform that d can be ported to, a 
single d make tool is surely going to be portable too.  I love "simple" 
things: one tool, one executable, no dependencies, fast operation, 
integration into d programs making the source itself the make script; 
pre-processor type directives are also possible here.
scons+python can be one .zip :)
6) Scons isn't always simple to set up (especially because of it's 
dependencies).  If your python is messed up for some reason, so is 
scons.  A single dmake tool won't inherit that problem.
I'm full dummy in linux but I installed python + scons very simply, no problems like in other soft.
I agree! Linux is very easy to install a working python system with scons: linux was about the only OS I found scons easy to install on. Windows on the other hand... is a pain. And other platforms?
7) Scons has a learning curve, even if it is small compared to some 
tools.  A dmake tool should be able to compile simple projects just by 
running it in the parent directory... practically no interaction for 
simple projects.  You can learn more powerful features as you go.  This 
is important for brand new users and new D programmers.
This curve pass during hour of reading and 1-2 days of practice.
Besides, what's wrong with starting another project?  What is it to you? 
 Is it that painful for you that other people might choose something 
else?  I feel for you, man.
Ok I'm not against, but reading this thread I understand that dbuild would not revolutional tool, inside dcommunity people still will use make, scons, other tools furthermore they will be used oftenly than dbuild. That was just my IMHO. Victor Nakoryakov nail-mail<at> mail<dot>ru
Victor, Victor ... what can I say? Scons must rule? Scons is the best thing in since pumpkin pie? I can't really argue with you on this because you've already made up your mind on the matter. Diversity makes this world interesting... currently D could use a few extra tools since it really has little in the build tool department. Let's let the proof be in the pudding. D won't grow much if every little attempt at improvement is trampled upon. In short, scons may be the nifty tool you describe. I really didn't intend to get caught up in a debate on that point. I'm just looking for alternatives that I think could make the process even simpler. I think there are other people here who are doing the same. Thanks for your input, nonetheless. :-) - John R.
Feb 11 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 I'm full dummy in linux but I installed python + scons very simply, no 
 problems
 like in other soft.
I agree! Linux is very easy to install a working python system with scons: linux was about the only OS I found scons easy to install on. Windows on the other hand... is a pain. And other platforms?
Scons was very easy to install on Mac OS X, and Python is pre-installed. 1) http://prdownloads.sourceforge.net/scons/scons-0.96.1-1.src.rpm 2) rpmbuild --rebuild scons-0.96.1-1.src.rpm 3) rpm2pkg scons-0.96.1-1.ppc.rpm Tada! (or one could just use the setup.py script. Me, I like packages) --anders
Feb 11 2005
prev sibling parent nail <nail_member pathlink.com> writes:
I agree! Linux is very easy to install a working python system with 
scons: linux was about the only OS I found scons easy to install on. 
Windows on the other hand... is a pain.  And other platforms?
WinXP had no problems with installation too.
Victor, Victor ... what can I say?  Scons must rule? Scons is the best 
thing in since pumpkin pie? I can't really argue with you on this 
because you've already made up your mind on the matter.
Well, I don't contend that scons is the best builder and it is impossible to develop smthing better. I mean the architecture of discussed dbuilder has lack of flexibility and such approach will not spit further than scons. Furthermore my point of view if we already have solution for building (make, scons) why not to concentrate on tools wich are not avaible for D. There are no native debuger, no native profiler (at least trace.log parser), no realy usable IDE or plugin to
Diversity makes this world interesting... currently D could use a few 
extra tools since it really has little in the build tool department. 
Let's let the proof be in the pudding.  D won't grow much if every 
little attempt at improvement is trampled upon.
See above.
In short, scons may be the nifty tool you describe.  I really didn't 
intend to get caught up in a debate on that point.  I'm just looking for 
alternatives that I think could make the process even simpler.  I think 
there are other people here who are doing the same.
Simpler? I wrote universal SConscript file that builds any *.d file under parent directory in lib, exe or what you want. Just copy it to new project and exec "scons" in the shell, what can be simpler? If somebody intrested, I'll e-mail script. Victor Nakoryakov nail-mail<at>mail<dot>com
Feb 11 2005
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
nail wrote:
 In article <cuhsgq$1ef4$1 digitaldaemon.com>, John Reimer says...
 
nail wrote:

In article <cuhbql$mtm$1 digitaldaemon.com>, John Reimer says...


SCons, scons, and one more time scons. Why to invent wheel twice? If your
arguments will "scons usualy not avaible after os installation like make" or
"scons uses python, not D" I'll disagree with you. It is unlikely dbuild will be
initialy avaible in os distrib and what is the difference what scripts to use
true python or new artificial?

BTW if someone russian will read dbuild aloud the result will be "moron" in
russian.
I've heard of Scons. I've used Scons. I don't think much of Scons. It's a great little tool. But we need something unattatched to a scripting language. I can't see Scons having the performance or flexibility of an open d make tool designed for the d system. I think something made for d using the d language is a good solution. Go ahead and disagree; you're good at it. Here are a few reasons why scons doesn't cut it (in my opinion): 1) Scons uses python ;-)
Haaa, haaa, haaa. And what? Looks like python is suitable only for building python scripts for python developers (lol, "building scripts":)
python is quite a large requirement if all you want to do is compile your program.
 
2) Scons does not support D pragmas() or versions statements (or does it?)
SCons support everything. The flexibility is enough to configure it for coffe cooking if blablabla.d is outdated.
kitchen sink.
3) Scons still needs a build file (something dbuild or dmake do not: 
they compile based on source alone)
Hm, and parameters? Will I have to write: dbuild --ignore-files="bla.d foo.d bar.d" --version=someversion --debug=5 --someoption=somevalue --somefoooption=somefoovalue --somebaroption=somebarvalue --somebazoption=somebazvalue --somemoreoption=somemorevalue --someoption=somevalue --someanotheroption=someanothervalue Great!
since you don't mind python you can write yourself a python script for that ;)
 
4) Scons uses python commands in it's config file: there's no choice 
there; therefore the build format is not negotiable.
How many different SConscripts I seen they all are totaly different. One build problem you can solve in veeeeeeeeery many ways using scons.
not everyone wants the kitchen sink
 
5) Scons is not a single entity/executable.

It's dependency is the whole python system.  Sure python has been ported 
almost everywhere; but for every platform that d can be ported to, a 
single d make tool is surely going to be portable too.  I love "simple" 
things: one tool, one executable, no dependencies, fast operation, 
integration into d programs making the source itself the make script; 
pre-processor type directives are also possible here.
scons+python can be one .zip :)
dmake can be a single file.
 
6) Scons isn't always simple to set up (especially because of it's 
dependencies).  If your python is messed up for some reason, so is 
scons.  A single dmake tool won't inherit that problem.
I'm full dummy in linux but I installed python + scons very simply, no problems like in other soft.
7) Scons has a learning curve, even if it is small compared to some 
tools.  A dmake tool should be able to compile simple projects just by 
running it in the parent directory... practically no interaction for 
simple projects.  You can learn more powerful features as you go.  This 
is important for brand new users and new D programmers.
This curve pass during hour of reading and 1-2 days of practice.
or you could use dmake with a 10 min learning curve
 
 
Besides, what's wrong with starting another project?  What is it to you? 
 Is it that painful for you that other people might choose something 
else?  I feel for you, man.
Ok I'm not against, but reading this thread I understand that dbuild would not revolutional tool, inside dcommunity people still will use make, scons, other tools furthermore they will be used oftenly than dbuild. That was just my IMHO.
I/we are not trying to force a new tool down your throat. We are just trying to get others to understand what an awesome tool it can be/already is for me.
 
 Victor Nakoryakov
 nail-mail<at> mail<dot>ru
Feb 11 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
New Ape wrote:

 The Makefile-related autotool programs are obsolete because of:
 
 (a) wasting time and cost in heavy environment inspections and expensive
dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on uncommon
 options of individual tools
<rant> Of course we need another Make tool! And another system language but C, and another version control system but CVS. The old ones are just sooo last century. Let's design and write and debug one each, from scratch... </rant> But if it means we can escape the current custom ones: win32.mak, linux.mak, darwin.mak, (etc. etc. etc.) Then I most certainly won't be just another nay-sayer... Just as long as it avoids XML (ant) and Python (scons), I'm OK. :-) --anders
Feb 11 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Bj鰎klund wrote:
 New Ape wrote:
 
 The Makefile-related autotool programs are obsolete because of:

 (a) wasting time and cost in heavy environment inspections and 
 expensive dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on 
 uncommon
 options of individual tools
<rant> Of course we need another Make tool! And another system language but C, and another version control system but CVS. The old ones are just sooo last century. Let's design and write and debug one each, from scratch... </rant> But if it means we can escape the current custom ones: win32.mak, linux.mak, darwin.mak, (etc. etc. etc.) Then I most certainly won't be just another nay-sayer... Just as long as it avoids XML (ant) and Python (scons), I'm OK. :-) --anders
Agreed. That's the idea. To avoid scripting languages and make config files. It just sucks in the source files and belches out the finished product. It automatically finds all required modules/dependencies in the project, all required libraries, links them up, and produces the product (library, dll, exe). Fine tuning of the compilation process can be controlled from with the d source with pragma/version statements (for advanced users). It's a fire and forget tool.
Feb 11 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 Agreed.  That's the idea.  To avoid scripting languages and make config 
 files.  It just sucks in the source files and belches out the finished 
 product.  It automatically finds all required modules/dependencies in 
 the project, all required libraries, links them up, and produces the 
 product (library, dll, exe).  Fine tuning of the compilation process can 
 be controlled from with the d source with pragma/version statements (for 
 advanced users).
 
 It's a fire and forget tool.
Changing source code to build differently sounds like a horrible idea. Hinting at which libraries are required to build is not a bad idea, and could be done with pragmas as suggested. But specifying things like linking options, or doing platform adjustments, etc. etc. ? No, I prefer a "Makefile" for those. (or build.xml or SConstruct) But if it is simple to find which files and libraries are needed to build a program, then the new tool could support that without *requring* a config file ? Using default rules and source pragmas. Just that I suspect that some kind of config will be needed, mostly. --anders
Feb 11 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Bj鰎klund wrote:
 John Reimer wrote:
 
 Agreed.  That's the idea.  To avoid scripting languages and make 
 config files.  It just sucks in the source files and belches out the 
 finished product.  It automatically finds all required 
 modules/dependencies in the project, all required libraries, links 
 them up, and produces the product (library, dll, exe).  Fine tuning of 
 the compilation process can be controlled from with the d source with 
 pragma/version statements (for advanced users).

 It's a fire and forget tool.
Changing source code to build differently sounds like a horrible idea. Hinting at which libraries are required to build is not a bad idea, and could be done with pragmas as suggested. But specifying things like linking options, or doing platform adjustments, etc. etc. ? No, I prefer a "Makefile" for those. (or build.xml or SConstruct) But if it is simple to find which files and libraries are needed to build a program, then the new tool could support that without *requring* a config file ? Using default rules and source pragmas. Just that I suspect that some kind of config will be needed, mostly. --anders
Fine. Then you probably aren't the target audience if you still prefer Makefiles. Stick with what you like. Or if you feel a real burden in this regard, try to make constructive suggestions to those that continue working on these tools instead deriding the ideas. Otherwise I suggest you not worry yourself about it.
Feb 11 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 Fine.  Then you probably aren't the target audience if you still prefer 
 Makefiles. Stick with what you like.  Or if you feel a real burden in 
 this regard, try to make constructive suggestions to those that continue 
 working on these tools instead deriding the ideas.  Otherwise I suggest 
 you not worry yourself about it.
But couldn't the proposed new build tool support both approaches ? Default rules for simple projects, overrides for more complex ones ? I just didn't think that including all of the current Makefile info or build.xml or SConstruct files into the source code was a good idea. Last time I looked at the Dmake tools (digc) they didn't even build OK, but I'll take another look and see if it works better now with GDC 0.10 DMD itself has a few new rules, like building a program with the same name instead of using "a.out" and a few other improvements like that... --anders
Feb 11 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Anders F Bj鰎klund wrote:
 John Reimer wrote:
 
 Fine.  Then you probably aren't the target audience if you still 
 prefer Makefiles. Stick with what you like.  Or if you feel a real 
 burden in this regard, try to make constructive suggestions to those 
 that continue working on these tools instead deriding the ideas.  
 Otherwise I suggest you not worry yourself about it.
But couldn't the proposed new build tool support both approaches ? Default rules for simple projects, overrides for more complex ones ?
Nothing is laid out in stone. If you make suggestions backed with strong arguments, perhaps they will be considered. Your ideas above are not beyond the realm of possibility.
 I just didn't think that including all of the current Makefile info
 or build.xml or SConstruct files into the source code was a good idea.
 Last time I looked at the Dmake tools (digc) they didn't even build OK,
 but I'll take another look and see if it works better now with GDC 0.10
Fair enough. My cursory comments should not be considered as an indication of what dmake or dbuild are going to be. Ideas must be considered, suggestion still need to be made. Just give it a chance before you reject it. As far as code source control of the build process, I like the idea, but I'm thinking more along the lines of what dmake offers. digc is old and outdated... I don't know if it compiles or even if it still works. But dmake borrowed some ideas from it so that's why it was included in this discussion. I still think we can use pragma/version statements to do some interesting source compilation control without a script file. Hopefully Derek will realease his "build" tool soon so you can see what he's done to it. I think people should at least see what these tools do and how they do it before they decide it's a waste of time.
 DMD itself has a few new rules, like building a program with the same
 name instead of using "a.out" and a few other improvements like that...
 
 --anders
small improvements, but good ones?
Feb 11 2005
prev sibling parent reply Alex Stevenson <ans104 cs.york.ac.uk> writes:
Anders F Bj鰎klund wrote:
 John Reimer wrote:
 
 Agreed.  That's the idea.  To avoid scripting languages and make 
 config files.  It just sucks in the source files and belches out the 
 finished product.  It automatically finds all required 
 modules/dependencies in the project, all required libraries, links 
 them up, and produces the product (library, dll, exe).  Fine tuning of 
 the compilation process can be controlled from with the d source with 
 pragma/version statements (for advanced users).

 It's a fire and forget tool.
Changing source code to build differently sounds like a horrible idea. Hinting at which libraries are required to build is not a bad idea, and could be done with pragmas as suggested. But specifying things like linking options, or doing platform adjustments, etc. etc. ? No, I prefer a "Makefile" for those. (or build.xml or SConstruct) But if it is simple to find which files and libraries are needed to build a program, then the new tool could support that without *requring* a config file ? Using default rules and source pragmas. Just that I suspect that some kind of config will be needed, mostly. --anders
I agree to a degree - I dislike Makefiles and similar devices, but I also don't like the idea of putting platform/linking information into the source files. I'd prefer to seperate out the implementation nasties of whether I'm linking against a windows dll stub or a linux libsomething.a library. Putting this sort of thing in the code feels too much like muddying my code with the nuts and bolts of the system. If for example I was using D on a platform a module/library writer hadn't anticipated me using I would potentially have to modify the source code to provide proper library file name formats (etc etc) even if the program compiles and links on my platform without any fuss. This could raise issues with licensing - GPL and all that. It could also interfere with some of the ad hoc debugging things I tend to do, like relink things with debug libraries to find particular bugs - I'd prefer not to have to anticipate and allow for all possible permutations of platform and debug setups in my source. Of course this might be my old-fashioned C programmer's resistance to change... I just turned 22, so I'm getting old and set in my ways :)
Feb 11 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Alex Stevenson wrote:
 Anders F Bj鰎klund wrote:
 
 John Reimer wrote:

 Agreed.  That's the idea.  To avoid scripting languages and make 
 config files.  It just sucks in the source files and belches out the 
 finished product.  It automatically finds all required 
 modules/dependencies in the project, all required libraries, links 
 them up, and produces the product (library, dll, exe).  Fine tuning 
 of the compilation process can be controlled from with the d source 
 with pragma/version statements (for advanced users).

 It's a fire and forget tool.
Changing source code to build differently sounds like a horrible idea. Hinting at which libraries are required to build is not a bad idea, and could be done with pragmas as suggested. But specifying things like linking options, or doing platform adjustments, etc. etc. ? No, I prefer a "Makefile" for those. (or build.xml or SConstruct) But if it is simple to find which files and libraries are needed to build a program, then the new tool could support that without *requring* a config file ? Using default rules and source pragmas. Just that I suspect that some kind of config will be needed, mostly. --anders
I agree to a degree - I dislike Makefiles and similar devices, but I also don't like the idea of putting platform/linking information into the source files. I'd prefer to seperate out the implementation nasties of whether I'm linking against a windows dll stub or a linux libsomething.a library. Putting this sort of thing in the code feels too much like muddying my code with the nuts and bolts of the system. If for example I was using D on a platform a module/library writer hadn't anticipated me using I would potentially have to modify the source code to provide proper library file name formats (etc etc) even if the program compiles and links on my platform without any fuss. This could raise issues with licensing - GPL and all that. It could also interfere with some of the ad hoc debugging things I tend to do, like relink things with debug libraries to find particular bugs - I'd prefer not to have to anticipate and allow for all possible permutations of platform and debug setups in my source. Of course this might be my old-fashioned C programmer's resistance to change... I just turned 22, so I'm getting old and set in my ways :)
Honestly, I think version statements could handle the above situations quite well. I think you and the others are thinking of worse case scenarios or are confusing this methodology with how bad the C/C++ preprocessor messes up the source. There is no need to sprinkle the compilation control all over the source tree if you don't want to. That's likely a bad idea. This process just makes use of a feature that has become a fixture of D: versioning. It just takes the step a little further. I think it fits well with D because it has already become standard practice for D to mix multi-platform code in a single source files (using version statements). Version/pragma control simply improves upon this feature. Compilation control can sit nicely in it's own module if you like. You could even have an independent "build.d" module for each platform you want to control the build process on. The advantage is that it sits in with the other source files well, but /only/ influences them in terms of compilation if the build tool is used (version(buildToolName) {...} defines the files use for the build tool only). This means dmd won't touch version(buildToolName) if you decide not to use the buildTool. Yet the file acts like a specification for the programs construction if you do go the buildTool route. The file is completely benign apart from the buildTool. The build.d module can also set global version values to further control compilation. Any process has the potential to be abused. It doesn't have to be that way. The build tools we're looking at are intended to ease the process. You have control over how much of a mess you want to make, but like everything else, it doesn't have to make a mess. If you stick to the same build process you would put in a Scons config file, but with finer control from a build module, there should be no problems. I don't quite understand why people are adverse to the idea, especially for those coming from the era of the C/C++ preprocessor (while useful and effective, the preprocessor is a horriblely messy control mechanism, IMO; or at least the result of overuse has become horrible messy). A good build tool and properly formated control mechanisms (version/pragma) could simplify the build process greatly. A good convention for creating the build configuration in a module should prevent people from the horrors they dream about. I'm getting very sleepy... I'm rambling on. I hope this wasn't too senseless! Later, John R.
Feb 11 2005
parent Alex Stevenson <ans104 cs.york.ac.uk> writes:
John Reimer wrote:
 Alex Stevenson wrote:
 
 Anders F Bj鰎klund wrote:

 John Reimer wrote:
  <<<Not much of relevance here :)>>>>
I'm getting very sleepy... I'm rambling on. I hope this wasn't too senseless! Later, John R.
Not at all - I think I'm starting to be won over to your point of view :)
Feb 11 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 It automatically finds all required modules/dependencies in the project, 
 all required libraries, links them up, and produces the product (library, 
 dll, exe).  Fine tuning of the compilation process can be controlled from 
 with the d source with pragma/version statements (for advanced users).
How does it find required libraries? I'm trying to picture how I would fit MinWin into an automatic make system. MinWin requires external GUI libraries. On Windows it requires gdi.lib. the Motif version requires libXm.a, libXt.a and libX11.a and looking at my make file the default library search path didn't include /usr/X11R6/lib so I had to add that. The GTK version requires libgtk-x11-2.0.a and libX11.a. My source code generally look like module foo; <some common stuff> version(Windows) { <Windows stuff> } else version (Motif) { <Motif stuff> } else version (GTK) { <GTK stuff> } Would I insert various version(build) pragma(...) in each of those version blocks? And for every file? I'm just asking how it would work. Also there is one file motif_aux.d that is imported by one of the files but it should not be linked in since it contains an "extern" variable declaration from one of the external libraries. Would I mark that up in some way? I can imagine version(build)pragma(nolink) extern (C) int externalFoo;
Feb 11 2005
parent reply Derek <derek psych.ward> writes:
On Fri, 11 Feb 2005 08:17:05 -0500, Ben Hinkle wrote:

 It automatically finds all required modules/dependencies in the project, 
 all required libraries, links them up, and produces the product (library, 
 dll, exe).  Fine tuning of the compilation process can be controlled from 
 with the d source with pragma/version statements (for advanced users).
How does it find required libraries? I'm trying to picture how I would fit MinWin into an automatic make system. MinWin requires external GUI libraries. On Windows it requires gdi.lib. the Motif version requires libXm.a, libXt.a and libX11.a and looking at my make file the default library search path didn't include /usr/X11R6/lib so I had to add that. The GTK version requires libgtk-x11-2.0.a and libX11.a. My source code generally look like module foo; <some common stuff> version(Windows) { <Windows stuff> } else version (Motif) { <Motif stuff> } else version (GTK) { <GTK stuff> } Would I insert various version(build) pragma(...) in each of those version blocks? And for every file? I'm just asking how it would work.
With my tool, it would look like ... module foo; <some common stuff> version(Windows) { version(build) pragma(link, gdi32); <Windows stuff> } else version (Motif) { version(build) pragma(link, somemotiflib, anothermotiflib); <Motif stuff> } else version (GTK) { version(build) { pragma(link, somegtklib); pragma(link, anothergtklib); } <GTK stuff> } You would only need this once, in your top level source file, though you can have these type of pragmas in as many places are you like. The libraries are only used on the link command line to build an executable. The idea is that the coder would know which libraries, if any, are needed.
 Also there is one file motif_aux.d that is imported by one of the files but 
 it should not be linked in since it contains an "extern" variable 
 declaration from one of the external libraries. Would I mark that up in some 
 way? I can imagine
 version(build)pragma(nolink)
 extern (C) int externalFoo;
Good idea. But let me get this straight, you want the motif_aux.d to be used by the compiler, but any motif_aux.obj created is to be ignored as, at link time, you will be getting the references from some library, right? If I've got this correct, I can add that in today. BTW, no one is going to force a tool like this on anyone. If it doesn't suit you then don't use it. -- Derek Melbourne, Australia
Feb 11 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Derek" <derek psych.ward> wrote in message 
news:42pi49in1ay3$.1dlrqzzn9c5bp$.dlg 40tude.net...
 On Fri, 11 Feb 2005 08:17:05 -0500, Ben Hinkle wrote:

 It automatically finds all required modules/dependencies in the project,
 all required libraries, links them up, and produces the product 
 (library,
 dll, exe).  Fine tuning of the compilation process can be controlled 
 from
 with the d source with pragma/version statements (for advanced users).
How does it find required libraries? I'm trying to picture how I would fit MinWin into an automatic make system. MinWin requires external GUI libraries. On Windows it requires gdi.lib. the Motif version requires libXm.a, libXt.a and libX11.a and looking at my make file the default library search path didn't include /usr/X11R6/lib so I had to add that. The GTK version requires libgtk-x11-2.0.a and libX11.a. My source code generally look like module foo; <some common stuff> version(Windows) { <Windows stuff> } else version (Motif) { <Motif stuff> } else version (GTK) { <GTK stuff> } Would I insert various version(build) pragma(...) in each of those version blocks? And for every file? I'm just asking how it would work.
With my tool, it would look like ... module foo; <some common stuff> version(Windows) { version(build) pragma(link, gdi32); <Windows stuff> } else version (Motif) { version(build) pragma(link, somemotiflib, anothermotiflib); <Motif stuff> } else version (GTK) { version(build) { pragma(link, somegtklib); pragma(link, anothergtklib); } <GTK stuff> } You would only need this once, in your top level source file, though you can have these type of pragmas in as many places are you like. The libraries are only used on the link command line to build an executable. The idea is that the coder would know which libraries, if any, are needed.
Can your tool build libraries? I build MinWin into a static library (like phobos). Now that I think about it maybe I won't put the link pragmas into the MinWin source since it doesn't actually need those libraries to build the MinWin library - it only needs them at the very end when building an executable.
 Also there is one file motif_aux.d that is imported by one of the files 
 but
 it should not be linked in since it contains an "extern" variable
 declaration from one of the external libraries. Would I mark that up in 
 some
 way? I can imagine
 version(build)pragma(nolink)
 extern (C) int externalFoo;
Good idea. But let me get this straight, you want the motif_aux.d to be used by the compiler, but any motif_aux.obj created is to be ignored as, at link time, you will be getting the references from some library, right? If I've got this correct, I can add that in today.
I never even bother compiling motif_aux.d to generate the object file. It is only imported in one of the source files. For the reason why see the thread about "extern(C) and data symbols" and in particular Walter's message http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15430
 BTW, no one is going to force a tool like this on anyone. If it doesn't
 suit you then don't use it.
I'm impressed you sort out all the version statements. That's very nice.
 -- 
 Derek
 Melbourne, Australia 
Feb 11 2005
parent reply Derek <derek psych.ward> writes:
On Fri, 11 Feb 2005 09:56:03 -0500, Ben Hinkle wrote:


[snip]

 Can your tool build libraries? I build MinWin into a static library (like 
 phobos). Now that I think about it maybe I won't put the link pragmas into 
 the MinWin source since it doesn't actually need those libraries to build 
 the MinWin library - it only needs them at the very end when building an 
 executable.
Yes. It assumes you want a library if it doesn't detect a main() or WinMain() function in the sources. This can be avoided by using the '-nolib' command line parameter. If it detects a main() or WinMain(), it assumes you want an executable created. That can be avoided by using the '-nolink' parameter. There is also a '-lib' parameter which forces a library to be created instead of an executable, in the case where you what the module with the main() to be placed in a library. There is a '-cleanup' parameter that removes all the .OBJ and other work files created during a run. There is also a '-link' parameter that forces the linker to be run in the case where it can't detect a main() but you what it linked anyway. (The main() might be in a library you supply). For example, if you provide both '-nolib' and '-nolink', it will compile all the modified sources to .OBJ form and not create a library and not create an executable. [snip]
 I'm impressed you sort out all the version statements. That's very nice.
I can't take credit for that. Helmut Leitner provided the algorithm and technique, I just fixed it up to catch some of the more esoteric syntax permutations. -- Derek Melbourne, Australia
Feb 11 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 There is also a '-lib' parameter which forces a library to be created
 instead of an executable, in the case where you what the module with the
 main() to be placed in a library.
bingo. cool.
 There is a '-cleanup' parameter that removes all the .OBJ and other work
 files created during a run.

 There is also a '-link' parameter that forces the linker to be run in the
 case where it can't detect a main() but you what it linked anyway. (The
 main() might be in a library you supply).
make sense.
 For example, if you provide both '-nolib' and '-nolink', it will compile
 all the modified sources to .OBJ form and not create a library and not
 create an executable.

 [snip]

 I'm impressed you sort out all the version statements. That's very nice.
I can't take credit for that. Helmut Leitner provided the algorithm and technique, I just fixed it up to catch some of the more esoteric syntax permutations. -- Derek Melbourne, Australia
I'm looking forward to trying it out.
Feb 11 2005
prev sibling next sibling parent reply Mark Junker <mjscod gmx.de> writes:
New Ape schrieb:

 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:
 
 (a) wasting time and cost in heavy environment inspections and expensive
dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on uncommon
 options of individual tools
I know that "make" sometimes is quite difficult to handle/maintain but it has the following advantages: - It's well known - It's well tested - It's quite easy to use when using autoconf/automake Regards, Mark
Feb 11 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Mark Junker wrote:
 New Ape schrieb:
 
 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:

 (a) wasting time and cost in heavy environment inspections and 
 expensive dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on 
 uncommon
 options of individual tools
I know that "make" sometimes is quite difficult to handle/maintain but it has the following advantages: - It's well known - It's well tested - It's quite easy to use when using autoconf/automake Regards, Mark
All good points if we are thinking about the experienced programmers; But those tools will always be available. You can use them if you prefer. These points do not lessen the need for a better tool for d. If these tasks can be vastly simplified with a d specific tool, it sure eases the learning curve for newcomers and saves tons of time and energy for the more experienced.
Feb 11 2005
prev sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Mark Junker wrote:
 New Ape schrieb:
 
 I know that "make" sometimes is quite difficult to handle/maintain but 
 it has the following advantages:
 - It's well known
 - It's well tested
 - It's quite easy to use when using autoconf/automake
But not all Makes are created equal. For example, the Digital Mars version, which I use when building with DMD on Windows, barfs on a lot of stuff the GNU version happily accepts. And there's no autoconf/automake for it. If you want to use GNU make on Win, then Cygwin or MSYS are a must.
Feb 11 2005
prev sibling parent reply "uframer" <uframer sina100.com.cn> writes:
"New Ape" <New_member pathlink.com>
写入消息新闻:cugtci$ahs$1 digitaldaemon.com...
 Dear DigitalMars and United Unix,

 Should we bother for Makefiles even on D?
 The Makefile-related autotool programs are obsolete because of:

 (a) wasting time and cost in heavy environment inspections and expensive 
 dynamic
 data genarations
 (b) these cheap-looked user-interfaces
 (c) these non-portable procedure-oriented data format that depends on 
 uncommon
 options of individual tools

 Thanks,
i'm gonna wait and see
Feb 12 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
uframer wrote:
 "New Ape" <New_member pathlink.com>
写入消息新闻:cugtci$ahs$1 digitaldaemon.com...
 
Dear DigitalMars and United Unix,

Should we bother for Makefiles even on D?
The Makefile-related autotool programs are obsolete because of:

(a) wasting time and cost in heavy environment inspections and expensive 
dynamic
data genarations
(b) these cheap-looked user-interfaces
(c) these non-portable procedure-oriented data format that depends on 
uncommon
options of individual tools

Thanks,
i'm gonna wait and see
Wow! I like that kind of attitude. :-)
Feb 12 2005
parent "uframer" <uframer sina100.com.cn> writes:
"John Reimer" <brk_6502 yahoo.com> ??????:cull1t$2bfc$1 digitaldaemon.com...
 uframer wrote:
 "New Ape" <New_member pathlink.com> 
 写入消息新闻:cugtci$ahs$1 digitaldaemon.com...

Dear DigitalMars and United Unix,

Should we bother for Makefiles even on D?
The Makefile-related autotool programs are obsolete because of:

(a) wasting time and cost in heavy environment inspections and expensive 
dynamic
data genarations
(b) these cheap-looked user-interfaces
(c) these non-portable procedure-oriented data format that depends on 
uncommon
options of individual tools

Thanks,
i'm gonna wait and see
Wow! I like that kind of attitude. :-)
i appreciate inovation , although it's risky
Feb 13 2005