July 13, 2011
"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
"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
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
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
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
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
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
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
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
"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.