February 11, 2005
Anders F Björklund 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?
February 11, 2005
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.
February 11, 2005
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

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 :)
February 11, 2005
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
February 11, 2005
Alex Stevenson wrote:
> 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
> 
> 
> 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.
February 11, 2005
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.
February 11, 2005
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
February 11, 2005
"zwang" <nehzgnaw@gmail.com> wrote in message news:cuhrq2$1cbn$1@digitaldaemon.com...
> 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"?

nice. Gets my vote  :-)


February 11, 2005
> 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;


February 11, 2005
John Reimer wrote:
> Alex Stevenson wrote:
> 
>> Anders F Björklund 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 :)