View mode: basic / threaded / horizontal-split · Log in · Help
February 11, 2005
Re: Mission: Makefile must die?
>
>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
any (comparable to C++/C#/Java) this is more important tasks I think.

>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
February 11, 2005
Re: Mission: Makefile must die?
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
February 11, 2005
Re: Mission: Makefile must die?
"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
February 11, 2005
Re: Mission: Makefile must die?
>> 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.
February 11, 2005
Re: Mission: Makefile must die?
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
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":)
> 
> 

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
February 12, 2005
Re: Mission: Makefile must die?
> 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.
February 12, 2005
Re: Mission: Makefile must die?
"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
February 12, 2005
Re: Mission: Makefile must die?
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. :-)
February 13, 2005
Re: Mission: Makefile must die?
"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
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home