"Jacob Carlborg" <doob@me.com> wrote in message news:ivng77$305d$1@digitalmars.com...
> On 2011-07-13 23:52, Nick Sabalausky wrote:
>> Hmm, yea, configure didn't even occur to me. I think it could acually be
>> done as just another File target that everything else depends on. Only
>> thing
>> is then you'd have to save/load the configuration file manually, so maybe
>> there should be some convenience mechnism for that (Maybe utilizing
>> Jacob's
>> Orange serialization library once that rewrite is done? Or maybe that
>> would
>> be overkill? Is there some INI-file util, or am I just imagining that?)
>
> What about doing something like DSSS/rebuild does. There are config files for dmd, ldc and gdc on various platforms. You can choose to invoke different compilers and it will use the config file for that particular compiler on the current platform.
>

One of my main goals for Drake is that using any old random tool (besides just building D code) doesn't feel like an afterthought. That DSSS/rebuild-style approach doesn't seem like it would scale particularly well in that direction. I think whatever solution is used needs to work just as well for the user's own custom tools as it does for DMD/LDC/GDC. Then, any D-specific simplifications/improvements that are made should be built on top of that. For example, we could provide a function the user calls from within their "configure" step that automatically handles D-specific configuring (And yea, maybe we could even automatically provide a default "configure" that already calls that function.)

On 2011-07-14 00:54, David Nadlinger wrote:
> On 7/13/11 11:41 PM, Nick Sabalausky wrote:
>>> "getDCompiler" seems unnecessary, both ldc and gdc have a dmd compatible
>>> wrapper, ldmd and gdmd. These wrappers takes the same flags as dmd and
>>> translate them to the correct "native" flags.
>>>
>>
>> That's great, I didn't know that. […]
>
> Be aware though that neither of them supports the -lib switch. By the
> way, does anyone have a wrapper emulating it for LDC lying around? That
> way, the Phobos build system wouldn't have to be duplicated for it, and
> e.g. the test suite could be built easily.
>
> David

http://pastebin.com/u2mBJDjA

-- 
/Jacob Carlborg

On 2011-07-14 04:37, Andrei Alexandrescu wrote:
> On 7/13/11 5:32 PM, Ulrik Mikaelsson wrote:
>> Not trying to be argumentative, but what exactly do you see as the
>> gains in having a D-buildtool built in D (or D-specific build-tool in
>> any language, for that matter)?
>
> I think it's a matter of positioning D and eating one's dogfood. If D is
> inconceivable for the kind of tasks that Python or Ruby are adept at,
> then sure, we could and should use either. On the other hand, if we
> advocate D as a good tool for short scripts, using the competition would
> hurt its brand.
>
> Personally I believe D is plenty adequate for short scripts, of which
> I've written a ton of. So the path of least resistance for a package
> manager or for a build tool is D, not any other language. I'd question
> much harder the decision of using another language (D is, however, not a
> competitor for the likes of bash or make).

Isn't it a competitor for make in this case?

> I see no NIH here. D is an ample language scaling up to large programs
> and down to scripts. If the question is to build a tool from scratch, D
> is the obvious choice and any other choice is just odd. It's like some
> tools I've seen (none successful) that required the competition's
> product to be installed in order to work.
>
>
> Andrei

I though we were talking about what language the build scripts should use, not the language the actual build tool should be written in. I think these are two separate issues and all tools mentioned (Drake, Orbit, Dake) in this thread are implemented in D.

My tools, using Ruby as the scripting language, have Ruby embedded in the tool and requires no installation of Ruby.

-- 
/Jacob Carlborg

On 2011-07-14 04:53, Andrej Mitrovic wrote:
> Why build a tool anyway? Why not make a build library that we can use
> in our build scripts?
>
> Then we just import the library in our `build.d` script, write the
> build script with the help of those library functions, and let the
> user run `rdmd build.d`. No need to install any tools, just run rdmd.
>
> I'm already using this approach for DWinProj., the only issue is that
> the build script is a little large (~300 lines), but a lot of its code
> could be put into a library (e.g. it has file traversing, parallel
> builds, checking if all tools are present, checking if all libraries
> are present, converting header files, etc..).
>
> This would reduce the script to a few dozen lines. And that's probably
> what I'll do to make my other projects easier to build.

I think a few dozen lines is way to much for a build script. If I choose to use all default configurations I want to only need to write one line:

target("main.d");

-- 
/Jacob Carlborg

On 2011-07-14 08:48, Russel Winder wrote:
> On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
> [ . . . ]
>> I think that one of the problem with these language independent build
>> tools is that they don't make it as easy as it could, because they
>> usually don't know enough about a given language.
>
> This is generally due to incomplete support in the tools, this is not a
> problem with general build frameworks per se.  In systems such as Waf
> and SCons, the framework provides facilities for creating tools and for
> those tools to build DAGs that then get "resolved" in the second phase
> of activity.  The language specific tool does things as a first phase of
> activity -- i.e. building the DAG.  The tools should realize all the
> language specific things that that languages users needs and/or the
> language expects.  Anything that is not handled is a problem that should
> be fixed by the tool maintainer.

Ok, I see, but it sounds complicated. And I basically give all my hope to the tool maintainer to be willing to merge/implement the necessary functionality/changes that the tool need to support D.

-- 
/Jacob Carlborg

On 2011-07-14 08:56, Russel Winder wrote:
> Nick,
>
> On Wed, 2011-07-13 at 17:41 -0400, Nick Sabalausky wrote:
> [ . . . ]
>> Yea, D is likely to be a little more verbose than what could be done in Ruby
>> (or Python). Personally, I think that's well worth it, though. I don't know
>> how many others would agree or not.
> [ . . . ]
>
> You might want to take a quick look at SBT -- the standard Scala build
> framework.  It's advocates started it because Ant and Maven are XML hell
> and are generally problematic, and Gradle is build on Java and Groovy,
> and (as you might expect) Scala folk abhor all things dynamic (i.e.
> Groovy) and insist on static type checking.  I have some doubts about
> the huge downloads they dump into each project hierarchy, but there is
> no doubt that they have made excellent use of a statically type language
> to create a DSL for building Scala things.
>
> If D can be used to go down this sort of road, and if it can support the
> build and install facilities of SCons and Waf, then it could be a
> winner.

Scala have a lot of features making a DSL looking a lot better than one written in D.

-- 
/Jacob Carlborg

On 7/14/11 9:53 PM, Jacob Carlborg wrote:
> On 2011-07-14 00:54, David Nadlinger wrote:
>> Be aware though that neither of them supports the -lib switch. By the
>> way, does anyone have a wrapper emulating it for LDC lying around? That
>> way, the Phobos build system wouldn't have to be duplicated for it, and
>> e.g. the test suite could be built easily.
>>
>> David
>
> http://pastebin.com/u2mBJDjA

Thanks, but my question was specifically about the »-lib« switch, which is not supported by the normal ldmd.

David

On 7/14/11, Jacob Carlborg <doob@me.com> wrote:
> I think a few dozen lines is way to much for a build script. If I choose to use all default configurations I want to only need to write one line:
>
> target("main.d");
>

I'm not talking about simple projects. I'm talking about libraries which might use other C libraries, where you need to download dependencies before building (due to licensing issues that prevent distribution for example) or invoke code generators, and check that the user has all the tools before building.

Have you seen the QtD CMakefile? It's almost 1000 lines.

"Jacob Carlborg" <doob@me.com> wrote in message news:ivniga$2lt$1@digitalmars.com...
> On 2011-07-14 08:48, Russel Winder wrote:
>> On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
>> [ . . . ]
>>> I think that one of the problem with these language independent build tools is that they don't make it as easy as it could, because they usually don't know enough about a given language.
>>
>> This is generally due to incomplete support in the tools, this is not a problem with general build frameworks per se.  In systems such as Waf and SCons, the framework provides facilities for creating tools and for those tools to build DAGs that then get "resolved" in the second phase of activity.  The language specific tool does things as a first phase of activity -- i.e. building the DAG.  The tools should realize all the language specific things that that languages users needs and/or the language expects.  Anything that is not handled is a problem that should be fixed by the tool maintainer.
>
> Ok, I see, but it sounds complicated. And I basically give all my hope to the tool maintainer to be willing to merge/implement the necessary functionality/changes that the tool need to support D.
>

Personally, I normally prefer just giving the commandline myself. I never feel comfortable trusting some generalized thing to do what I want or to be flexible enough to let me reliably make all adjustments I might need to make.

Nick Sabalausky wrote:
> Ultimately, I think going with a rake/scons-like build-system approach just allows for a little bit more boilerplate to be removed, which is good for something like a buildscript. For example, if done as a library, once you've defined all your targets, you'd have to call some function to actually do the build. As a build system, defining the targets is all you need to do, and the build gets invoked automatically. It's kinda like how dmain() calls the user's main() instead of the work inside dmain() being a library functions that the main() author needs to call. Plus, as a build-system, the "void main(string[] args) {" part can eventually be removed (once sticking normally-module-level things inside a function is mature enough, if it isn't already).

It is not mature at all.
Module-level things inside functions do not currently work well:

Eg:

- No forward references.
- No forward references, reloaded:
void main(){
    int foo();
    int bar(){return foo();} // ok
    int foo(){return 100;}   // nope, *!* this is called a "redefinition" *!*
}


- No (template) overloading:
void main(){
    int foo(int x){return x;}
    double foo(double x){return x;} // nope
    int bar(int x)(){return x;}
    double bar(double x)(){return x;} // nope
}

Those limitations are very itchy (at least for the kind of stuff I'd like to be doing), and should be removed.

Cheers,
-Timon