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