View mode: basic / threaded / horizontal-split · Log in · Help
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]
"Kagamin" <spam@here.lot> wrote in message 
news:ivjlkm$1amf$1@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> From: "Russel Winder" <russel@russel.org.uk>
>> >
>> >I agree with the premise that package management must be a core part of
>> >the build management,
>>
>> If I understand what you're saying correctly, then I strongly disagree. A
>> package management tool, by necessity, must be a common agreed-upon 
>> standard
>> (otherwise it won't serve it's purpose). But if that package management 
>> is
>> tied into build management then we're *also* forcing a single standard 
>> build
>> system on everyone. So then instead of being able to choose your build
>> system, everyone now has to come to an agreement on the same build 
>> system,
>> which #1: Is unlikely to ever happen, and #2: Serves no useful purpose.
>
> A build tool should be able to invoke a package manager and package 
> manager should be able to invoke a build tool, this doesn't mean a tie, it 
> means a working out of the box solution.

Ok, that does make sense.

>This solution is meant to just work. If people don't want solution that 
>just works, they can go with something else of course. For example I prefer 
>makefiles.
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message 
news:mailman.1593.1310541508.14074.digitalmars-d@puremagic.com...
> On Wednesday 13 July 2011 03:01:04 Nick Sabalausky wrote:
>> Regarding this topic's frequent ressurection, I see that as a direct 
>> result
>> of it all being *merely* talk, with very little concrete progress. We 
>> don't
>> even *have* a proper package management system (there's DSSS, but it's 
>> dead,
>> bitrotted, and I don't think it handles dependencies or multiple versions
>> of the same package). So naturally that topic's going to keep coming up
>> until we have something.
>
> I belive that Jacob Carlborg is working on a solution. So,  there _is_ 
> work
> being done on it.

Right. And I'm definitely keeping an eye on Orb. I just meant that the lack 
of a D package manager that's already usable (and still living) is the main 
reason this all keeps getting discussed every so often.

> By no means does that mean that you shouldn't work on a
> solution, but it's not the case that no one has been working on the 
> problem -
> though it is true that it's been being brought up for far longer than it's
> been being worked on.
>

Yea, I didn't mean that nobody's working on it. Just that, for package 
management, there isn't really much usable right now, and for build 
management, there isn't anything that doesn't rely on either makefiles or 
XML or some non-D dynamic langauge/interpreter, etc.
July 13, 2011
Re: Prototype buildsystem "Drake"
I asked about build tools for D on the mailing list a while ago. I 
needed a solution that allowed me to mix C++ and D builds in a 
cross-platform way with minimum fuss. You can find the discussion about 
it here 
<http://www.digitalmars.com/d/archives/digitalmars/D/Best_build_tool_for_D_projects_136103.html> 
(you were also a part of it IIRC). My biggest requirement at the time was:

 * Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
   to an absolute minimum. What's the point in a cross-platform
   language if when you build projects in it you need to write a short
   essay for the build system...
 * Pre-built binaries available to all platforms (or as many as possible).

In the end I settled for Jam (ftjam) 
<http://www.freetype.org/jam/index.html>, it works tremendously well. 
It's easy to get binaries for almost any operating system (especially 
with projects like homebrew <http://mxcl.github.com/homebrew/> for Mac). 
I have very few gripes with it:

 * The build description language is very simple (once you fully grok
   it), but could have done with a lot more example-based documentation.
 * It's missing a few features like recursive-directory scanning (for
   source files), and the ability to pipe the output from a program
   into a variable in the build script (e.g. C++FLAGS = `llvm-config
   --cxxflags`).
 * A convenient way to force all generated object and library files
   into a dedicated build folder. It's possible but not very easy to do.
 * I'm a big fan of convention over configuration, I know it's a very
   subjective topic but I like the way Maven3 and Gradle assume a
   project structure (that you can deviate from if you need to). This
   usually requires very good supporting documentation.

The build script I put together for my project looked like this, 
http://mysticpaste.com/private/TCcTE6KGxn .

Hope this helps,

Chris


On 07/13/11 02:02, Nick Sabalausky wrote:
> The recent discussions about package managers and buildsystems has prompted
> me to get off my ass (or rather, *on* my ass as per how programming is
> usually performed...) and start on the D-based rake-inspired buildtool I've
> been meaning to make for awhile now. It's not actually usable yet, but
> there's a sample drakefile demonstrating everything, and it does actually
> compile and run (but just doesn't build the dependency tree or actually run
> any of the build steps). *Should* work on Posix, but I only tested on
> Windows, so I may have fucked up the Posix version...
>
> Apologies to Jacob Carlborg for the name being so close to "dake". Didn't
> really know what else to call it ("Duck", maybe?) Like dake, it's inspired
> by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
> Ruby, which was my #1 reason for making a Rake alternative.
>
> Before I go implemeting everything, I'd like to get input on it. Is it
> something that could be a major D tool?
>
> Overview of Drake and links to all the code are here:
>
> https://bitbucket.org/Abscissa256/drake/wiki/Home
>
>
July 13, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-13 03:02, Nick Sabalausky wrote:
> The recent discussions about package managers and buildsystems has prompted
> me to get off my ass (or rather, *on* my ass as per how programming is
> usually performed...) and start on the D-based rake-inspired buildtool I've
> been meaning to make for awhile now. It's not actually usable yet, but
> there's a sample drakefile demonstrating everything, and it does actually
> compile and run (but just doesn't build the dependency tree or actually run
> any of the build steps). *Should* work on Posix, but I only tested on
> Windows, so I may have fucked up the Posix version...
>
> Apologies to Jacob Carlborg for the name being so close to "dake". Didn't
> really know what else to call it ("Duck", maybe?) Like dake, it's inspired
> by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
> Ruby, which was my #1 reason for making a Rake alternative.
>
> Before I go implemeting everything, I'd like to get input on it. Is it
> something that could be a major D tool?
>
> Overview of Drake and links to all the code are here:
>
> https://bitbucket.org/Abscissa256/drake/wiki/Home

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. But instead of starting a 
debate between Ruby and D I'm going to give you a few suggestions and 
comments instead.

The minimal drakefile doesn't look that minimal. This is the idea I have 
for a minimal build script file:

target("main.d"); // builds "main.d" as an executable

Or:

target("foobar"); // builds the directory "foobar" as a library

DSSS did this very good.

Now looking in the drakefile.d. You have targets and tasks all over the 
place, almost every target has "Task" as a template parameter. Why is 
this necessary? Have one function for targets and one for tasks. Example 
from the drakefile.d:

        target!Task("upload", "all",
                (Target t)
                {
                        system("ftp ...");
                }
        );

Seems this could look like this:

task("upload", "all", {
    system("ftp...");
}); // if D just could get a better looking delegate syntax

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

The "drakfile" function seems unnecessary. I would use a string import 
(or what it's called), importing the whole build script into a method in 
a class. All code in the "drakefile" function would instead be at top level.

Most of the functions called in the build script should be instance 
methods, this will allow to use threading, possible invoke multiple 
targets/tasks simultaneously and running several build scripts 
simultaneously.

I see installation related code in the build script. I think a package 
manager should be responsible for that. A build tool should deal with 
single files and a package manager should deal with packages (of files).

-- 
/Jacob Carlborg
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]
On 2011-07-13 07:10, Russel Winder wrote:
> I think that in order to create a momentum, a fundamental choice needs
> to be made:
>
> --  Should D have a specialist tool (à la SBT/Scala, Leiningen/Clojure
> -- at the risk of massive NIH-ism, just as the Scala and Clojure folk
> appear to have) or go with a generalist tool such as Gradle or SCons.

I think that we should go for a D specific build tool.

-- 
/Jacob Carlborg
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]
On 2011-07-13 07:28, Jonathan M Davis wrote:
> On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:
>> And, of course, I should have mentioned CMake and CMakeD.
>>
>> The fact that I forgot, shows my prejudice against Makefile-based
>> systems and for direct DAG-based systems such as Gradle, SCons and Waf.
>> This though should not stop CMakeD being a part of this debate.
>
>> From previous discussions, it seems that one of the primary reasons for having
> a D build tool in many people's minds is to also handle package management of
> D libraries (like Haskell's cabal or rubygems for ruby). And as great as
> cmaked, scons, gradle, waf, and other such tools may be, they don't do that.
>
> - Jonathan M Davis

I don't agree with that. I think a build tool should deal with single 
files and building. A package manager should deal with packages (of 
files). In Ruby, RubyGems is the package manager and Rake is the build tool.

-- 
/Jacob Carlborg
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]
On 2011-07-13 09:18, Jonathan M Davis wrote:
> On Wednesday 13 July 2011 03:01:04 Nick Sabalausky wrote:
>> Regarding this topic's frequent ressurection, I see that as a direct result
>> of it all being *merely* talk, with very little concrete progress. We don't
>> even *have* a proper package management system (there's DSSS, but it's dead,
>> bitrotted, and I don't think it handles dependencies or multiple versions
>> of the same package). So naturally that topic's going to keep coming up
>> until we have something.
>
> I belive that Jacob Carlborg is working on a solution. So,  there _is_ work
> being done on it. By no means does that mean that you shouldn't work on a
> solution, but it's not the case that no one has been working on the problem -
> though it is true that it's been being brought up for far longer than it's
> been being worked on.
>
> - Jonathan M Davis

Yes, I do work on that. And a build tool as well.

-- 
/Jacob Carlborg
July 13, 2011
Re Build system requirements [ was Re: Prototype buildsystem "Drake" ]
On Wed, 2011-07-13 at 17:33 +0200, Jacob Carlborg wrote:

> target("main.d"); // builds "main.d" as an executable

The SCons equivalent is:

	Program ( 'main.d' )

> Or:
> 
> target("foobar"); // builds the directory "foobar" as a library

SCons (and I think Waf as well) does not support this idea (at least
currently).  In SCons you have to say:

	SharedLibrary ( 'libraryRootName' , Glob ( 'foobar/*.d' ) )
	StaticLibrary ( 'libraryRootName' , Glob ( 'foobar/*.d' ) )

D support in Waf is currently far more sophisticated than that of SCons,
but is still based on being a bit more explicit that your proposal
above.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake"]
On 2011-07-13 08:36, Jacob Carlborg wrote:
> On 2011-07-13 07:28, Jonathan M Davis wrote:
> > On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:
> >> And, of course, I should have mentioned CMake and CMakeD.
> >> 
> >> The fact that I forgot, shows my prejudice against Makefile-based
> >> systems and for direct DAG-based systems such as Gradle, SCons and Waf.
> >> This though should not stop CMakeD being a part of this debate.
> >> 
> >> From previous discussions, it seems that one of the primary reasons for
> >> having
> > 
> > a D build tool in many people's minds is to also handle package
> > management of D libraries (like Haskell's cabal or rubygems for ruby).
> > And as great as cmaked, scons, gradle, waf, and other such tools may be,
> > they don't do that.
> > 
> > - Jonathan M Davis
> 
> I don't agree with that. I think a build tool should deal with single
> files and building. A package manager should deal with packages (of
> files). In Ruby, RubyGems is the package manager and Rake is the build
> tool.

Well, I'm not advocating anything in particular. I was just pointing out that 
a big part of the discussions on build tools has been package management of 
libraries, and any build tool solution which doesn't at least integrate with 
some sort of package management solution is likely to not be what at least 
some people are looking for.

Personally, I don't generally use package management tools for handling 
libraries even with languages that have such tools, and I don't generally use 
much in the way of build tools either beyond simple scripts (primarily because 
I don't generally have projects large enough for it to be an issue). As it 
stands, if I were to choose a build tool for a larger project, I'd probably 
choose CmakeD, but I'm not super-familiar with all of the tools out there and 
haven't generally found much use for them.

I was just trying to point out that a fair bit of the discussion for such 
tools in this list has related to package management, and Nick's solution 
doesn't address that at all AFAIK.

- Jonathan m Davis
July 13, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake"]
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message 
news:mailman.1611.1310578056.14074.digitalmars-d@puremagic.com...
> On 2011-07-13 08:36, Jacob Carlborg wrote:
>>
>> I don't agree with that. I think a build tool should deal with single
>> files and building. A package manager should deal with packages (of
>> files). In Ruby, RubyGems is the package manager and Rake is the build
>> tool.
>
> Well, I'm not advocating anything in particular. I was just pointing out 
> that
> a big part of the discussions on build tools has been package management 
> of
> libraries, and any build tool solution which doesn't at least integrate 
> with
> some sort of package management solution is likely to not be what at least
> some people are looking for.
>
> Personally, I don't generally use package management tools for handling
> libraries even with languages that have such tools, and I don't generally 
> use
> much in the way of build tools either beyond simple scripts (primarily 
> because
> I don't generally have projects large enough for it to be an issue). As it
> stands, if I were to choose a build tool for a larger project, I'd 
> probably
> choose CmakeD, but I'm not super-familiar with all of the tools out there 
> and
> haven't generally found much use for them.
>
> I was just trying to point out that a fair bit of the discussion for such
> tools in this list has related to package management, and Nick's solution
> doesn't address that at all AFAIK.
>

Fair enough. And yea, my solution doesn't even try to address package 
management since it considers that a separate issue. May have been a little 
misleading for me to bring up those discussions in the first place. Really 
what happened was just: For a long time I'd been meaning to make a Rake-like 
tool based on D, Jacob posted his Rake-like tool based on Ruby, and that lit 
a fire under me to finally get started on mine.

Although I have to admit, I've only now started to look at Waf. While I 
definitely still wouldn't want to use it for D projects (for reasons I've 
already mentioned), it does have some interesting design elements that I'm 
going to have to think about.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home