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.

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

Anders F Björklund 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"?

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.

Anders F Björklund 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.

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

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

Anders F Björklund 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.

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

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.