On 7/14/11 3:09 PM, Jacob Carlborg wrote:
> 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.

Does it have something akin to string mixins?

Andrei

Timon Gehr wrote:
> 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

Oh, I forgot: template constraints seem to be lexically invalid on local templates.

Cheers,
-Timon

"Ulrik Mikaelsson" <ulrik.mikaelsson@gmail.com> wrote in message news:mailman.1620.1310596361.14074.digitalmars-d@puremagic.com...
> 2011/7/13 Nick Sabalausky <a@a.a>:
>> "Jacob Carlborg" <doob@me.com> wrote in message news:ivke5k$2m78$1@digitalmars.com...
>>>
>>> First I have to say that I know you are doing this because you want to
>>> use
>>> D as the language for the build scripts. The reason I did choose Ruby
>>> because I think D will be too verbose and when I'm looking at
>>> drakefile.d
>>> I do think it's too verbose.
>>
>> 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.
>>
>
> 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)? Seriously, I'm really asking, since I'm having a hard time seeing it?

Perfectly understandable question. First of all, it isn't really a D-specific tool, it's intended to be usable for anything (including D, of course). It's just that it's written in D and it uses buildscripts that are written in D.

As for why a new one based on D instead of just using Rake/SCons/Waf/etc., like Andrei said, there's the dogfooding and brand image issues. Also:

- D programmers and people working on D projects don't have to learn or switch to another language for their buildscripts.

- D projects don't have to be dependent on other languages or VMs. Although I have to say I was impressed that Jacob's Ruby-buildscript-based Dake avoids this problem.

- Utility functions can easily be shared between a D program and it's build script (for whatever that's worth, but I can imagine it could come in handy now and then).

- Also, I just like D a lot more than I like Ruby/Python and I think it's safe to assume there are probably other D users who feel the same (since they're D users after all).


> Personally, I can only see the
> drawbacks;
>
> * Building druntime and phobos might be difficult with a d-based buildtool

Those already use make, and I'm not sure that's really going to change.


> * The build-tool itself will need bootstrapping. A user that wants to test some D-project, will first have to aquire (build) and install some D-compiler with custom tools. Then install druntime with another custom build-system. Then Phobos. Then drake. And THEN, the application/library he/she was interested in. Shortening this path is IMHO REALLY important to see more D adoption. From my personal experience, convincing developers and testers to fight through this path is HARD.

It's not as complicated as you suggest. Suppose someone wants to try building FooApp:

Step 1: D compilers already come prebuilt, with Phobos and Druntime already set up. So just install DMD. Done. Or users can install DVM and then install DMD with "dvm install {version} && dvm use -d (version)".

Step 2: Install drake. Or, FooApp could even just include Drake. Or, FooApp could be installed with a package manager that sees FooApp depends on Drake and so auto-installs Drake first.

Step 3: Run "drake all". That invokes a trivial one-line shell/batch script that will automatically compile drake and the buildscript (if they're not already built), and then run the buildscript.

Or, when we get a good package manager, we could just offer pre-built versions of the package manager and then:

Step 1: Install the package manager (which might even install DMD automatically, possibly via DVM).

Step 2: Run "d-package-manager install FooApp". The package manager determines FooApp depends on DMD and Drake (and maybe DVM), and automatically installs all of that, then installs FooApp and invokes FooApp's post-install script which is "drake all", and thus builds FooApp.

Step 3: Enjoy a nice latte, because you're done.


> * Cross-language builds (project with bindings), and builds with external targets might be more difficult than need be, if the "2nd" language is not supported by drake.

One of my primary goals for Drake is that anything you can do on the command line can easily be done with Drake. So that amounts to pretty much any language. Drake doesn't require special bindings to use any particular tool (although bindings to abstract away the command line can be made, if desired)


> * Verbose build-script is IMHO a _really_ undesireable trait.

Fair enough point. It's possible I might not be able to get it quite as terse as some systems, but I am trying my best to minimize verbosity. I think the cross-platform extensions like "foo".exe are a good example of that. It uses the trickery of module-level "properties" combined with UFCS to achieve what I think may be the simplest possible D syntax for cross-platform file extensions (at least without getting too crazy).


> * How soon will I as a developer be able to "just build" a D-binding to a C++-app (with needed C-glue-code) in Drake? Will a user of, say Gentoo, be able to count on this working in his/her envrironment too?

TBH, I'm not exactly well-versed in linking C++ and D. Actually, I've never even looked into it, let along done it...

Basically, if you know how to do it on the command line, then you can "just do it" in Drake. If you're looking for something more magical, then I'd say "Whenever someone writes an abstraction for it".


> * Non-compilation actions will have to be reimplemented; document generation, test execution, install-tasks following OS-specific install procedures (XDG-guidelines etc.), ...
>

Not really sure what you mean here.


> IMHO, it sounds like a case of the NIH-syndrome, but I might be missing something obvious?

I suppose someone could argue that it's NIH, technically speaking. (Personally, I feel that anti-NIH sentiment is overrated.) But I think it's worthwhile just to be able to write buildscripts in D. After all, nobody really *has* to use D for anything. They can just write their apps in C, C++, Java, Ruby, Python, etc. But a growing number of people use D because they like it and feel it provides certain benefits. So I guess I'd say: Why shouldn't we be able to write buildscripts in D and make use of a helpful framework/library to do it?

On 2011-07-14 21:15, Nick Sabalausky wrote:
> I assume you meant "mixin" instead of "writeln".

Doesn't matter. It's the import statement I'm referring to.

> What I meant is that, suppose wr have this:
>
>      // internal_to_drake.d:
>      void main()
>      {
>          mixin(import("main.d"));
>      }
>
>      // main.d:
>      import blah;
>      // rest of buildscript...
>
> Then that becomes:
>
>      void main()
>      {
>          import blah;
>          // rest of buildscript...
>      }
>
> And *that's* a brand-new feature. And I think there may be some other
> things, too, that might still be a little buggy if they're stuck inside a
> function like that.

Ah, now I see. I'm hoping the user never needs to write import statements in the build script. It's just these little things that I don't like about using D for the build scripts. Imports and no top level code.

>>> - I wasn't sure if a D file that isn't strictly a proper D file would be
>>> too
>>> weird, too confusing, too magical, or would confuse the fuck out of
>>> advanced
>>> IDE's.
>>
>> I have no idea how an IDE would behave with an incomplete file like that.
>> I pretty sure this only matters if the IDE does some semantic processing,
>> i.e. something more than just syntax highlighting. Textmate, which
>> basically only does syntax highlighting, has no problem with an incomplete
>> D file.
>>
>
> Right, but a lot of people use fancy IDE's like Eclipse and Visual Studio.

Exactly.

> Maybe you're thinking D1? I *think* the thread-local-by-default is D2-only
> (though I'm not certain).

I was thinking in Ruby, but I've already answered this in another post.

-- 
/Jacob Carlborg

On 2011-07-14 21:18, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:ivnfk8$2v3p$1@digitalmars.com...
>> On 2011-07-13 23:03, jdrewsen wrote:
>>>
>>> A good start I think. The first thing that I think should be fixed is
>>> the naming.
>>>
>>> Drake should be called dbuild
>>> Orb should be called dpack
>>>
>>> You read the name and you have an idea of what it does - nothing fancy.
>>
>> "Drake" was probably chosen because it's basically "rake for D" and
>> possibly because "dake" was already taken. "rake" was most likely chosen
>> because it's "make" but the makefiles are written in Ruby instead.
>>
>> I chose "Orbit" as the name of the package manager and named the tool
>> "Orb". Why? No particular reason, but after that someone mentioned it has
>> the same theme as (Digital)Mars and Phobos.
>>
>
> Between "Orb" and "Orange" I was thinking you just liked using names based
> on round things :)

Hehe. I actually started using names of fruits for my projects (I have an unreleased library named "lime"), don't really know why I chose Orbit.

-- 
/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.

If you want to run arbitrary tasks with the build tool? You would need some handling of command line arguments. It just seems more complicated than having a dedicated build tool

-- 
/Jacob Carlborg

On 2011-07-14 21:34, Nick Sabalausky wrote:
> That said, making Drake's functionality at least available in library form
> does sound like a good idea. And the buildscript-wrapping system (for people
> who want it) can, of course, be built on top of that.

The functionality of the build tool should absolutly be built as a library, then creating a thin wrapper around the library which will be the actual tool the user invokes. This will allow to have the build tool built into an IDE or similar.

Have a look at Orbit, the install command for example:

https://github.com/jacob-carlborg/orbit/blob/master/orbit/orb/commands/Install.d

Just two lines to do the invoke the installer (which could be one line).

-- 
/Jacob Carlborg

On 2011-07-14 22:13, David Nadlinger wrote:
> 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

Oh, I see.

-- 
/Jacob Carlborg

On 2011-07-14 21:50, Nick Sabalausky wrote:
> "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.)

Ok, have you thought about how this will look (in code) and behave?

-- 
/Jacob Carlborg

On 2011-07-14 22:25, Andrej Mitrovic wrote:
> 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.

Ok. I rather not look at a 1000 line cmakefile :)

-- 
/Jacob Carlborg