View mode: basic / threaded / horizontal-split · Log in · Help
February 11, 2005
Re: Mission: Makefile must die?
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.
February 11, 2005
Re: Mission: Makefile must die?
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
February 11, 2005
Re: Mission: Makefile must die?
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"?
February 11, 2005
Re: Mission: Makefile must die?
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.
February 11, 2005
Re: Mission: Makefile must die?
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.
February 11, 2005
Re: Mission: Makefile must die?
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
February 11, 2005
Re: Mission: Makefile must die?
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
February 11, 2005
Re: Mission: Makefile must die?
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.
February 11, 2005
Re: Mission: Makefile must die?
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
February 11, 2005
Re: Mission: Makefile must die?
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.
1 2 3 4
Top | Discussion index | About this forum | D home