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


1 2 3 4
Next ›   Last »