View mode: basic / threaded / horizontal-split · Log in · Help
February 11, 2005
Re: Mission: Makefile must die?
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
Re: Mission: Makefile must die?
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
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

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
Re: Mission: Makefile must die?
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
Re: Mission: Makefile must die?
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
Re: Mission: Makefile must die?
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
Re: Mission: Makefile must die?
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
Re: Mission: Makefile must die?
"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
Re: Mission: Makefile must die?
> 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
Re: Mission: Makefile must die?
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 :)
1 2 3 4
Top | Discussion index | About this forum | D home