www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SCons support for D

reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

SCons is a Python-based build tool to replace Make and much of the
Autotools functionality.  It has D support as part of the core.  This
support is though in need of development.

The new Mercurial/BitBucket infrastructure for developing SCons
(replacing the old Subversion/Tigris set up) is now in place, a new
release 2.1.0 has been declared and everything is open for business
leading to a 2.2.0 release.

I got my changes to support DMD 2 into this release :-)

However, support for GDC, LDC, etc. is almost certainly still sadly
lacking, and indeed the support for DMD almost certainly needs a severe
refactoring and most likely a rewrite.

Rather than people having to work on a clone of SCons in order to work
on the tool, I have created a separate Mercurial repository
(https://bitbucket.org/russel/scons_dmd_new) as a development version of
just the tool.  When a new version of this separate tool is declared I
create a pull request for the SCons mainline to get the new version in
the next version of SCons.

Is anyone else other than me interested in using SCons as a build tool
with D code?  If there is, perhaps we can collaborate in some way to
progress SCons support for all the various realizations of D?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Dec 06 2011
next sibling parent eles <eles eles.com> writes:
 Is anyone else other than me interested in using SCons as a build tool
 with D code?  If there is, perhaps we can collaborate in some way to
 progress SCons support for all the various realizations of D?

I am interested. SCons is my build tool of choice (for C/C++),a lthough I also use fbuild (see on github) sometimes. I am not very good at Python, but I could give a helping hand if needed. I will ask you on the bitbucket site
Dec 06 2011
prev sibling next sibling parent reply Andrew Gough <andrew goughy.org> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 06 Dec 2011 18:14:25 +0000
Russel Winder <russel russel.org.uk> wrote:

 SCons is a Python-based build tool to replace Make and much of the
 Autotools functionality.  It has D support as part of the core.  This
 support is though in need of development.
=20
 The new Mercurial/BitBucket infrastructure for developing SCons
 (replacing the old Subversion/Tigris set up) is now in place, a new
 release 2.1.0 has been declared and everything is open for business
 leading to a 2.2.0 release.
=20
 I got my changes to support DMD 2 into this release :-)
=20
 However, support for GDC, LDC, etc. is almost certainly still sadly
 lacking, and indeed the support for DMD almost certainly needs a
 severe refactoring and most likely a rewrite.
=20
 Rather than people having to work on a clone of SCons in order to work
 on the tool, I have created a separate Mercurial repository
 (https://bitbucket.org/russel/scons_dmd_new) as a development version
 of just the tool.  When a new version of this separate tool is
 declared I create a pull request for the SCons mainline to get the
 new version in the next version of SCons.
=20
 Is anyone else other than me interested in using SCons as a build tool
 with D code?  If there is, perhaps we can collaborate in some way to
 progress SCons support for all the various realizations of D?
=20

I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake. Would it be a good idea to thrash out the arguments for/against a particular tool, and build/support just one? The community doesn't seem big enough to be so fragmented. Java has Ant, Scala has sbt - surely D should have a canonical build tool? --=20 Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 07 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 10:27, Andrew Gough wrote:
 On Tue, 06 Dec 2011 18:14:25 +0000
 Russel Winder<russel russel.org.uk>  wrote:

 SCons is a Python-based build tool to replace Make and much of the
 Autotools functionality.  It has D support as part of the core.  This
 support is though in need of development.

 The new Mercurial/BitBucket infrastructure for developing SCons
 (replacing the old Subversion/Tigris set up) is now in place, a new
 release 2.1.0 has been declared and everything is open for business
 leading to a 2.2.0 release.

 I got my changes to support DMD 2 into this release :-)

 However, support for GDC, LDC, etc. is almost certainly still sadly
 lacking, and indeed the support for DMD almost certainly needs a
 severe refactoring and most likely a rewrite.

 Rather than people having to work on a clone of SCons in order to work
 on the tool, I have created a separate Mercurial repository
 (https://bitbucket.org/russel/scons_dmd_new) as a development version
 of just the tool.  When a new version of this separate tool is
 declared I create a pull request for the SCons mainline to get the
 new version in the next version of SCons.

 Is anyone else other than me interested in using SCons as a build tool
 with D code?  If there is, perhaps we can collaborate in some way to
 progress SCons support for all the various realizations of D?

I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake.

Orbit is a package manager and not a build tool. -- /Jacob Carlborg
Dec 07 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-07 10:54, Russel Winder wrote:
 On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote:
 [...]
 I think the build tool question is in need of the same level of high
 level design and support that Steve Teale is working on for
 std.database/std.sql.

I am not sure I quite get that, sorry.
 It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS
 (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D
 support to premake.

As far as I am aware the C, C++, Fortran communities use Make, Autotools, SCons, CMake or Waf. I suspect they have never heard of DSSS, xfbuild, dake or rdmd ;-)
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, D, OCaml, etc. It works nicely for multi-target, multi-platform builds. I use Waf for "ship the source, compile on installation" FOSS projects. I have given up on Autotools. CMake's language is dreadful so I only use that if necessary. Java has Gradle, Maven, Gant, and Ant. Using Ant for builds is like using assembly language to create GUI applications -- possible but not recommended. Scala has sbt because the Scala community couldn't abide the multi-languages approach, everything has to be Scala. Clojure has a similar philosophy and hence Leiningen. Sure D can use D as the build specification language and follow the inward looking Scala and Clojure approaches of creating a new tool for build. But that is just trying to create a closed system. Is this closed approach really what the D community wants to do -- is following the Scala and Clojure philosophy desirable? The advantage of Gradle and Maven as build tools for JVM based systems is that you can write multi-lingual systems and build them. Java, Scala, Groovy, JRuby, Clojure -- all can be used in a single system. sbt has problems with this since it assumes all source is Scala (more or less). The Java community is rapidly giving up its "Java is all you need" attitude and is looking positively at the polyglot approach. D sits in a context of C, C++, Fortran (possible others?) which means something like SCons, Waf and CMake which has support for all these already baked in seems like a "less work" way forward. So the strategy is one of: Do we work with a build framework that exists and already allows serious build using D; or do we start from scratch with a new build framework that no-one can use till something is ready?

What I see as the advantage of a new build system is that it can be developed specifically for D which could make the tool very easy to use. Example: $ tool build main.d That's all that should be needed to build an executable. You could have the same in a build script: // buildfile main.d $ tool build For a library it should be similar: $ tool build foo Where "foo" is a directory. I don't know if that's possible to have in a build tool not specifically developed for D. -- /Jacob Carlborg
Dec 07 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-07 15:06, Russel Winder wrote:
 On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
 [...]
 What I see as the advantage of a new build system is that it can be
 developed specifically for D which could make the tool very easy to use.
 Example:

 $ tool build main.d

Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build.

There are still cases when special flags are needed and how is the library dependencies resolved?
 This is the logical extension of the "convention over configuration"
 approach developed by Maven and Gradle to such great effect.

I think that makes sense. It should be the default but it should still be possible to use a custom project structure.
 That's all that should be needed to build an executable. You could have
 the same in a build script:

 // buildfile
 main.d

Too much data ;-)

Hehe. It's the same amount of data, just moved from the command line into a build script. The comment was to make it clear it was in a build script.
 $ tool build

 For a library it should be similar:

 $ tool build foo

 Where "foo" is a directory. I don't know if that's possible to have in a
 build tool not specifically developed for D.

I still worry about a language specific tool. Language plugins to general tools make far more sense to me.

Well, can the above be simplicity be achieved if an existing tool is used? -- /Jacob Carlborg
Dec 07 2011
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Jacob Carlborg Wrote:

 On 2011-12-07 15:06, Russel Winder wrote:
 On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
 [...]
 What I see as the advantage of a new build system is that it can be
 developed specifically for D which could make the tool very easy to use.
 Example:

 $ tool build main.d

Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build.

There are still cases when special flags are needed and how is the library dependencies resolved?

There are still makefiles required. You just need to include the standard definitions Makefile (application, package) and define a few standard variables that describe your project. There are also some conventions regarding to which processor and operating system your Go files refer to. More information here: http://golang.org/doc/code.html
Dec 07 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 16:49, Paulo Pinto wrote:
 Jacob Carlborg Wrote:

 On 2011-12-07 15:06, Russel Winder wrote:
 On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
 [...]
 What I see as the advantage of a new build system is that it can be
 developed specifically for D which could make the tool very easy to use.
 Example:

 $ tool build main.d

Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build.

There are still cases when special flags are needed and how is the library dependencies resolved?

There are still makefiles required. You just need to include the standard definitions Makefile (application, package) and define a few standard variables that describe your project. There are also some conventions regarding to which processor and operating system your Go files refer to. More information here: http://golang.org/doc/code.html

I see. -- /Jacob Carlborg
Dec 07 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 15:15, Gour wrote:
 On Wed, 07 Dec 2011 14:38:04 +0100
 Jacob Carlborg<doob me.com>  wrote:

 What I see as the advantage of a new build system is that it can be
 developed specifically for D which could make the tool very easy to
 use. Example:

 $ tool build main.d

 That's all that should be needed to build an executable. You could
 have the same in a build script:

 // buildfile
 main.d

 $ tool build

 For a library it should be similar:

 $ tool build foo

 Where "foo" is a directory. I don't know if that's possible to have
 in a build tool not specifically developed for D.

Hmm...isn0t it too simplistic? For our project, we have need to e.g. buil lib from the included sources of 3rd party C library, then use SWIG to provide D bindings for it, then build D libs using those bindings and only then buil D executable. That's why we're targetting CMake/CPack and want to help Jens to push D support upstream(the only problem is we're a bit short on time atm.) Sincerely, Gour

Of course it should be possible to build more complex projects and have more options in the build script. But for simple projects nothing more should be needed. The above would be the minimum to actually build something. For an executable that doesn't have any dependencies (except for the standard library) noting more should be needed. -- /Jacob Carlborg
Dec 07 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 19:02, Russel Winder wrote:
 On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
 [...]
 Example:

 $ tool build main.d

 That's all that should be needed to build an executable. You could have
 the same in a build script:

 // buildfile
 main.d

 $ tool build

Currently with SCons, you type: $ scons and the default activity occurs. With the SConstruct file: Program ( "main.d" ) the result is the construction of the executable, ready for execution.

Ok, sounds good. But I'm not sure if I like that you just have to invoke "scons" without any action or flag. In the tools I've written lately it will out put the usage information if you just invoke "tool". I'm not sure what I like best.
 If there is to be a D specific build tool then I would suggest that
 there has to be even less work than using SCons for it to be appealing.
 So my current "straw man" use case would be that there is no
 configuration file at all just a naming convention and a default target
 so that:

 $ tool

 infers the project structure and compiles the executable -- i.e.
 something along the lines of what Go is doing since it eschewed Make as
 the standard build tool.

That should be doable.
 For a library it should be similar:

 $ tool build foo

 Where "foo" is a directory. I don't know if that's possible to have in a
 build tool not specifically developed for D.

With SCons you specify the list of object files that comprise the archive or the shared object depending on whether it is a static library or a shared library. The list is generally constructed programmatically, so for example, something akin to: contributors = Glob ( '*.d' ) Library ( 'flob' , contributors ) SharedLibrary ( 'flob' , contributors )

That's quite could but a bit unnecessary for the simplest cases. Just specifying a folder should be enough.
 I am sure a convention could make this such that no specification would
 be needed.  If we could come up with a executable and library project
 convention it could be encoded in the SCons dmd tool so it can improve
 and continue to act as a straw man against which arguments can be made.

I think that should be doable, perhaps something like this: project |-- src |-- main.d // executable target |-- project // library target Or: project |-- src |-- project |-- main.d "project" would be a library target if "main.d" doesn't exist. Otherwise "main.d" will be an executable target. After a build: project |-- bin // executable is placed here |-- lib // libraries are placed here |-- imports // imports are placed here I'm not entirely sure where I want to place "main.d". -- /Jacob Carlborg
Dec 07 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 19:02, Russel Winder wrote:
 On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
 [...]
 Example:

 $ tool build main.d

 That's all that should be needed to build an executable. You could have
 the same in a build script:

 // buildfile
 main.d

 $ tool build

Currently with SCons, you type: $ scons and the default activity occurs. With the SConstruct file: Program ( "main.d" ) the result is the construction of the executable, ready for execution.

If I understand everything correctly Scons uses Python for its build scripts and that means an external dependency on Python? I think that's unnecessary and I would prefer that interpreter was bundled with the tool i.e. linked with libpython (or similar). I think that will make it easier for non Linux users. That's how I've built my package manager. It has no external dependencies when using a pre-compiled executable. -- /Jacob Carlborg
Dec 08 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 15:03, Russel Winder wrote:
 Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen,
 Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the
 overall effect of a "focused on D" build tool, whether build from
 scratch or over another framework.  Specialist per language build tools
 lead to a ghettoization.  Even 5 mins looking at the Rake, sbt and
 Leiningen situations make this abundantly clear.  Which is sad as there
 are many good things about all of them.

Rake isn't targeted to a single language. It's just as make but with a different syntax for the script files. If you take a look at the official tutorial you can see that they use C in the examples. -- /Jacob Carlborg
Dec 07 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-07 20:56, Jens Mueller wrote:
 I'm unsure whether D needs its own configuration/build tool. It
 definitely needs a package manager.

 For building there are different options but usually it's make. Most
 people (at least for sure on Unix variants) are using it. I think Scons
 does both building and configuring. Just want to say that you can have
 different tools for these jobs or single one.
 Jacob's build tool looks good but I wonder what are the major
 improvements over e.g. make (portability is an issue with make; maybe
 simplicity).

Makefiles are a horrible thing of this world.
 For configuring there are some options and so far none of them is
 preferred by a majority. Different people weigh different aspects
 differently. But it seems people are moving away from configure scripts.

 As Russell already said, several build/configuration tools are used and
 there is no clear winner in general. So I think it's very nice that you
 have added support for D to premake. So we then have SCons (build and
 configuration), CMake (configuration and several build tools via
 generators), rdmd (can generate dependencies for Makefile), Jacob as a
 build tool and there are several others specifically for D and premake.

 I'm not sure about the state of each of these. But SCons and CMake work
 with dmd (both do configuration). premake is also configuration.
 Regarding build tools I wonder how important they are. make works fairly
 well.

 Jens

I want a simple portable build tool. DSSS was/is a good tool, but it's not maintained anymore. It had some problems but I like it in general. -- /Jacob Carlborg
Dec 07 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-07 23:31, Jens Mueller wrote:
 Gour wrote:
 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu<turkeyman gmail.com>  wrote:

 premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.

Didn't hear about premake before...how does it compare with e.g. Cmake?

The nice thing about premake is that it is build using Lua. So you have a full language at your disposal. CMake's configuration language is not that nice or at least it takes time to get used to it. premake only concerns itself with configuring. Which I think is nice. But it has nothing similar to CMake's find_package last time I checked.

Is Lua an external dependency or compiled into the executable? -- /Jacob Carlborg
Dec 08 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-08 09:15, Brad Anderson wrote:
 On Thu, Dec 8, 2011 at 1:06 AM, Jacob Carlborg <doob me.com
     Is Lua an external dependency or compiled into the executable?

     --
     /Jacob Carlborg


 It's built in.  Premake is distributed as a single executable on all
 platforms.

That's good and I think that's how all build tools should do. -- /Jacob Carlborg
Dec 08 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-08 10:13, Andrew Gough wrote:
 The reasons I chose premake were primarily:

 1. No external dependencies (lua embedded in an executable)
 2. Simple configuration
 3. Cross platform
 4. Generates native build scripts: make, VS, Code::Blocks etc etc

 I have to point out that I have only added DMD+make support as that is
 all I needed at the time, but have plans (who doesn't :-D) to add
 support for LDC, GDC, and other build chains.

So it depends on external build tools. I don't like that. I guess it could have an option to generate makefiles or similar but by default it should be able to build on its own. -- /Jacob Carlborg
Dec 08 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-08 12:18, Andrew Gough wrote:
 On Thu, 08 Dec 2011 11:23:18 +0100
 Jacob Carlborg<doob me.com>  wrote:

 On 2011-12-08 10:13, Andrew Gough wrote:
 The reasons I chose premake were primarily:

 1. No external dependencies (lua embedded in an executable)
 2. Simple configuration
 3. Cross platform
 4. Generates native build scripts: make, VS, Code::Blocks etc etc

 I have to point out that I have only added DMD+make support as that
 is all I needed at the time, but have plans (who doesn't :-D) to add
 support for LDC, GDC, and other build chains.

So it depends on external build tools. I don't like that. I guess it could have an option to generate makefiles or similar but by default it should be able to build on its own.

No problem. I disagree and think that a cross platform build generator that leverages native build tools is a better approach and provides more flexibility in the long run. Particularly for Windows VS users or people tied to an IDE - configuration that generates to various IDE build scripts keeps those devs happier IMO

I don't agree. -- /Jacob Carlborg
Dec 08 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-08 16:19, Kagamin wrote:
 No problem. I disagree and think that a cross platform build generator
 that leverages native build tools is a better approach and provides
 more flexibility in the long run. Particularly for Windows VS users or
 people tied to an IDE - configuration that generates to various IDE
 build scripts keeps those devs happier IMO

Well, native projects do make developers happier, but if the tool can't build on its own, there's no reason to use it, if make just works. premake will be a burden of an extra level to go through.

Make is a burden. -- /Jacob Carlborg
Dec 08 2011
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 12/8/2011 6:13 PM, Andrew Gough wrote:
 On Wed, 7 Dec 2011 20:56:17 +0100
 Jens Mueller<jens.k.mueller gmx.de>  wrote:

 Andrew Gough wrote:
 On Tue, 06 Dec 2011 18:14:25 +0000
 Russel Winder<russel russel.org.uk>  wrote:

 SCons is a Python-based build tool to replace Make and much of the
 Autotools functionality.  It has D support as part of the core.
 This support is though in need of development.

 The new Mercurial/BitBucket infrastructure for developing SCons
 (replacing the old Subversion/Tigris set up) is now in place, a
 new release 2.1.0 has been declared and everything is open for
 business leading to a 2.2.0 release.

 I got my changes to support DMD 2 into this release :-)

 However, support for GDC, LDC, etc. is almost certainly still
 sadly lacking, and indeed the support for DMD almost certainly
 needs a severe refactoring and most likely a rewrite.

 Rather than people having to work on a clone of SCons in order to
 work on the tool, I have created a separate Mercurial repository
 (https://bitbucket.org/russel/scons_dmd_new) as a development
 version of just the tool.  When a new version of this separate
 tool is declared I create a pull request for the SCons mainline
 to get the new version in the next version of SCons.

 Is anyone else other than me interested in using SCons as a build
 tool with D code?  If there is, perhaps we can collaborate in
 some way to progress SCons support for all the various
 realizations of D?

I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake.

Where do I find your changes for premake?

https://bitbucket.org/goughy/premake-dev-d
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens

The reasons I chose premake were primarily: 1. No external dependencies (lua embedded in an executable) 2. Simple configuration 3. Cross platform 4. Generates native build scripts: make, VS, Code::Blocks etc etc I have to point out that I have only added DMD+make support as that is all I needed at the time, but have plans (who doesn't :-D) to add support for LDC, GDC, and other build chains.

I've considered doing this several times in the past. Managing the makefiles in Derelict has been a PITA, to say the least. Thanks for sharing this!
Dec 08 2011
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 12/8/2011 6:29 PM, Andrew Gough wrote:
 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu<turkeyman gmail.com>  wrote:

 premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.
 GDC is also important. Great news! :)

I'd be happy to continue - I simply got my fork working for DMD+make and just use it locally. It was reviewed by premake's author and he seemed happy with the implementation, but I haven't gotten around to providing an upstream patch. If there is enough interest, I can fix up some loose ends and try and get the ball rolling again...

+1
Dec 08 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrew Gough" <andrew goughy.org> wrote in message 
news:20111207202725.5adae172 goughy.org...
It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS
(D1 only?), xfbuild, dake, rdmd options - I've added preliminary D
support to premake.

xfbuild and rdmd are not really build managers. They're just frontends to the compiler which add the modern ability to just specify the main .d file instead of having to specify all the .d files.
Would it be a good idea to thrash out the arguments for/against a
particular tool, and build/support just one? The community doesn't
seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
surely D should have a canonical build tool?

I think we can get there, it's just that none of the existing ones are really up to that level yet: - xfbuild and rdmd, like I said, aren't really n the same category - SCons relies on and creates a dependency on another language, and not everyone's going to like that (and not everyone likes Python) - CMake relies on make and a lot of people would just rather let make die than build things on top of it. - Orbit, like someone else said, is a package manager, not a build tool. - DSSS/rebuild has beed dead and abandoned for a long time. - dake (as well as my alternative approach, tentatively "drake") just isn't ready yet.
Dec 08 2011
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 12/9/2011 2:04 AM, Gour wrote:
 On Thu, 8 Dec 2011 20:13:29 +1100
 Andrew Gough<andrew goughy.org>  wrote:

 I have to point out that I have only added DMD+make support as that is
 all I needed at the time, but have plans (who doesn't :-D) to add
 support for LDC, GDC, and other build chains.

Does premake support building SWIG extensions? Sincerely, Gour

Not out of the box, but it would be trivial to add as a custom Action.
Dec 08 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote:
[...]
 I think the build tool question is in need of the same level of high
 level design and support that Steve Teale is working on for
 std.database/std.sql.

I am not sure I quite get that, sorry.
 It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS
 (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D
 support to premake.

As far as I am aware the C, C++, Fortran communities use Make, Autotools, SCons, CMake or Waf. I suspect they have never heard of DSSS, xfbuild, dake or rdmd ;-)
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, D, OCaml, etc. It works nicely for multi-target, multi-platform builds. I use Waf for "ship the source, compile on installation" FOSS projects. I have given up on Autotools. CMake's language is dreadful so I only use that if necessary. Java has Gradle, Maven, Gant, and Ant. Using Ant for builds is like using assembly language to create GUI applications -- possible but not recommended. Scala has sbt because the Scala community couldn't abide the multi-languages approach, everything has to be Scala. Clojure has a similar philosophy and hence Leiningen. Sure D can use D as the build specification language and follow the inward looking Scala and Clojure approaches of creating a new tool for build. But that is just trying to create a closed system. Is this closed approach really what the D community wants to do -- is following the Scala and Clojure philosophy desirable? The advantage of Gradle and Maven as build tools for JVM based systems is that you can write multi-lingual systems and build them. Java, Scala, Groovy, JRuby, Clojure -- all can be used in a single system. sbt has problems with this since it assumes all source is Scala (more or less). The Java community is rapidly giving up its "Java is all you need" attitude and is looking positively at the polyglot approach. D sits in a context of C, C++, Fortran (possible others?) which means something like SCons, Waf and CMake which has support for all these already baked in seems like a "less work" way forward. So the strategy is one of: Do we work with a build framework that exists and already allows serious build using D; or do we start from scratch with a new build framework that no-one can use till something is ready? =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Dec 07 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 07 Dec 2011 09:54:08 +0000
Russel Winder <russel russel.org.uk> wrote:

 On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote:
 [...]
 I think the build tool question is in need of the same level of high
 level design and support that Steve Teale is working on for
 std.database/std.sql.

I am not sure I quite get that, sorry.

I'm suggesting that the current multi-pronged approach to providing a workable build system is hampered by the multitude of directions and could benefit from some initial discussion, consensus and design.
=20
 It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS
 (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D
 support to premake.

As far as I am aware the C, C++, Fortran communities use Make, Autotools, SCons, CMake or Waf. I suspect they have never heard of DSSS, xfbuild, dake or rdmd ;-)

I agree that it would be good to use a tool with support for multiple languages & platforms. I was trying to point out that the multitude of options is potentially harmful.
=20
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, D, OCaml, etc. It works nicely for multi-target, multi-platform builds. I use Waf for "ship the source, compile on installation" FOSS projects. I have given up on Autotools. CMake's language is dreadful so I only use that if necessary. =20 Java has Gradle, Maven, Gant, and Ant. Using Ant for builds is like using assembly language to create GUI applications -- possible but not recommended. =20

Simple Ant scripts are easy, but XML is a very bad choice for a build system IMO=20
 Scala has sbt because the Scala community couldn't abide the
 multi-languages approach, everything has to be Scala.  Clojure has a
 similar philosophy and hence Leiningen.
=20
 Sure D can use D as the build specification language and follow the
 inward looking Scala and Clojure approaches of creating a new tool for
 build.  But that is just trying to create a closed system.  Is this
 closed approach really what the D community wants to do -- is
 following the Scala and Clojure philosophy desirable?
=20

Not really what I was suggesting - I was hoping to discuss consolidating effort around a small set of tools, rather than the current state.
 The advantage of Gradle and Maven as build tools for JVM based systems
 is that you can write multi-lingual systems and build them.  Java,
 Scala, Groovy, JRuby, Clojure -- all can be used in a single system.
 sbt has problems with this since it assumes all source is Scala (more
 or less).  The Java community is rapidly giving up its "Java is all
 you need" attitude and is looking positively at the polyglot approach.
=20
 D sits in a context of C, C++, Fortran (possible others?) which means
 something like SCons, Waf and CMake which has support for all these
 already baked in seems like a "less work" way forward.
=20
 So the strategy is one of:
=20
 Do we work with a build framework that exists and already allows
 serious build using D; or
=20

Possibly.
 do we start from scratch with a new build framework that no-one can
 use till something is ready?
 =20

Possibly (if necessary) I thought it important to have a discussion first to determine the requirements and use cases, and concentrate effort rather than disperse it. --=20 Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-07 at 22:00 +1100, Andrew Gough wrote:
[...]
 I'm suggesting that the current multi-pronged approach to providing a
 workable build system is hampered by the multitude of directions and
 could benefit from some initial discussion, consensus and design.

OK. It is a valid point, effort is being diluted. On the other hand various people prefer different systems, so I am not sure there is any constructive point in dictating the "one true build system". If there were one that gained a majority support votes then it could concentrate available effort. [...]
 I agree that it would be good to use a tool with support for multiple
 languages & platforms.  I was trying to point out that the multitude of
 options is potentially harmful.

Or an opportunity? D is trying to supplant C, C++, Fortran and Python. D should therefore be buildable with the same tools that people use with these languages in order to provide the lowest possible barrier to entry to D of C, C++, Fortran and Python programmers. Not having to change build system but simply to add to their current build system makes transition easier. [...]
 Simple Ant scripts are easy, but XML is a very bad choice for a build
 system IMO=20

XML was an interesting choice originally, but has been perverted beyond sanity in the Ant context. This is why I wrote Gant -- use all the Ant tasks but not from the XML interpreter but from Groovy scripts. The idea cannot have been all bad as it inspired Hans Dockter to create Gradle, and the Apache folk forked Gant to create the Groovy frontend to Ant. [...]
=20
 Not really what I was suggesting - I was hoping to discuss
 consolidating effort around a small set of tools, rather than the
 current state.

I fully appreciate the idea is to focus effort so as to avoid dilution. With the effort available it is a good idea. I am just not convinced creating new tools from scratch is the right approach. [...]
 Do we work with a build framework that exists and already allows
 serious build using D; or

Possibly. =20
 do we start from scratch with a new build framework that no-one can
 use till something is ready?

Possibly (if necessary) =20 I thought it important to have a discussion first to determine the requirements and use cases, and concentrate effort rather than disperse it.

Having a full and frank exchange of views is an excellent move. As long as everyone stays friends! Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen, Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the overall effect of a "focused on D" build tool, whether build from scratch or over another framework. Specialist per language build tools lead to a ghettoization. Even 5 mins looking at the Rake, sbt and Leiningen situations make this abundantly clear. Which is sad as there are many good things about all of them. If there effort to start from scratch with D to create the replacement for Make, CMake, Autotools, as a general build framework, that is a different issue. But this is a big undertaking requiring DAGs, C scanners, C++ scanners, Fortran scanners, LaTeX scanners, etc., not to mention tool finders and toolchain builders. My current prejudice is that SCons, Waf and CMake already have almost all of this stuff already in place, so it is an incremental step to make sure they work well with D (*). (*) Though due to various bits of history, the project lead of Waf has declared me persona non grata, so I cannot actually contribute to Waf and its D support :-(( =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Dec 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
[...]
 What I see as the advantage of a new build system is that it can be=20
 developed specifically for D which could make the tool very easy to use.=

 Example:
=20
 $ tool build main.d

Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build. This is the logical extension of the "convention over configuration" approach developed by Maven and Gradle to such great effect.=20
 That's all that should be needed to build an executable. You could have=

 the same in a build script:
=20
 // buildfile
 main.d

Too much data ;-)
 $ tool build
=20
 For a library it should be similar:
=20
 $ tool build foo
=20
 Where "foo" is a directory. I don't know if that's possible to have in a=

 build tool not specifically developed for D.

I still worry about a language specific tool. Language plugins to general tools make far more sense to me. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Dec 07 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 07 Dec 2011 14:38:04 +0100
Jacob Carlborg <doob me.com> wrote:

 What I see as the advantage of a new build system is that it can be=20
 developed specifically for D which could make the tool very easy to
 use. Example:
=20
 $ tool build main.d
=20
 That's all that should be needed to build an executable. You could
 have the same in a build script:
=20
 // buildfile
 main.d
=20
 $ tool build
=20
 For a library it should be similar:
=20
 $ tool build foo
=20
 Where "foo" is a directory. I don't know if that's possible to have
 in a build tool not specifically developed for D.

Hmm...isn0t it too simplistic? For our project, we have need to e.g. buil lib from the included sources of 3rd party C library, then use SWIG to provide D bindings for it, then build D libs using those bindings and only then buil D executable. That's why we're targetting CMake/CPack and want to help Jens to push D support upstream(the only problem is we're a bit short on time atm.) Sincerely, Gour --=20 As the ignorant perform their duties with attachment to results,=20 the learned may similarly act, but without attachment, for the=20 sake of leading people on the right path. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 07 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
[...]
 Example:
=20
 $ tool build main.d
=20
 That's all that should be needed to build an executable. You could have=

 the same in a build script:
=20
 // buildfile
 main.d
=20
 $ tool build

Currently with SCons, you type: $ scons and the default activity occurs. With the SConstruct file: Program ( "main.d" ) the result is the construction of the executable, ready for execution. If there is to be a D specific build tool then I would suggest that there has to be even less work than using SCons for it to be appealing. So my current "straw man" use case would be that there is no configuration file at all just a naming convention and a default target so that: $ tool infers the project structure and compiles the executable -- i.e. something along the lines of what Go is doing since it eschewed Make as the standard build tool.
 For a library it should be similar:
=20
 $ tool build foo
=20
 Where "foo" is a directory. I don't know if that's possible to have in a=

 build tool not specifically developed for D.

With SCons you specify the list of object files that comprise the archive or the shared object depending on whether it is a static library or a shared library. The list is generally constructed programmatically, so for example, something akin to: contributors =3D Glob ( '*.d' ) Library ( 'flob' , contributors ) SharedLibrary ( 'flob' , contributors ) I am sure a convention could make this such that no specification would be needed. If we could come up with a executable and library project convention it could be encoded in the SCons dmd tool so it can improve and continue to act as a straw man against which arguments can be made. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Dec 07 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Andrew Gough wrote:
 On Tue, 06 Dec 2011 18:14:25 +0000
 Russel Winder <russel russel.org.uk> wrote:
 
 SCons is a Python-based build tool to replace Make and much of the
 Autotools functionality.  It has D support as part of the core.  This
 support is though in need of development.
 
 The new Mercurial/BitBucket infrastructure for developing SCons
 (replacing the old Subversion/Tigris set up) is now in place, a new
 release 2.1.0 has been declared and everything is open for business
 leading to a 2.2.0 release.
 
 I got my changes to support DMD 2 into this release :-)
 
 However, support for GDC, LDC, etc. is almost certainly still sadly
 lacking, and indeed the support for DMD almost certainly needs a
 severe refactoring and most likely a rewrite.
 
 Rather than people having to work on a clone of SCons in order to work
 on the tool, I have created a separate Mercurial repository
 (https://bitbucket.org/russel/scons_dmd_new) as a development version
 of just the tool.  When a new version of this separate tool is
 declared I create a pull request for the SCons mainline to get the
 new version in the next version of SCons.
 
 Is anyone else other than me interested in using SCons as a build tool
 with D code?  If there is, perhaps we can collaborate in some way to
 progress SCons support for all the various realizations of D?
 

I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake.

Where do I find your changes for premake?
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens
Dec 07 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0016367f97ceb6e5eb04b3868c7a
Content-Type: text/plain; charset=UTF-8

premake supports D? I was planning to add D support to premake myself, but
that's wonderful news. I'll add support for VisualD if it is not already
done.
GDC is also important. Great news! :)

On 7 December 2011 21:56, Jens Mueller <jens.k.mueller gmx.de> wrote:

 Andrew Gough wrote:
 On Tue, 06 Dec 2011 18:14:25 +0000
 Russel Winder <russel russel.org.uk> wrote:

 SCons is a Python-based build tool to replace Make and much of the
 Autotools functionality.  It has D support as part of the core.  This
 support is though in need of development.

 The new Mercurial/BitBucket infrastructure for developing SCons
 (replacing the old Subversion/Tigris set up) is now in place, a new
 release 2.1.0 has been declared and everything is open for business
 leading to a 2.2.0 release.

 I got my changes to support DMD 2 into this release :-)

 However, support for GDC, LDC, etc. is almost certainly still sadly
 lacking, and indeed the support for DMD almost certainly needs a
 severe refactoring and most likely a rewrite.

 Rather than people having to work on a clone of SCons in order to work
 on the tool, I have created a separate Mercurial repository
 (https://bitbucket.org/russel/scons_dmd_new) as a development version
 of just the tool.  When a new version of this separate tool is
 declared I create a pull request for the SCons mainline to get the
 new version in the next version of SCons.

 Is anyone else other than me interested in using SCons as a build tool
 with D code?  If there is, perhaps we can collaborate in some way to
 progress SCons support for all the various realizations of D?

I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake.

Where do I find your changes for premake?
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens

--0016367f97ceb6e5eb04b3868c7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable premake supports D? I was planning to add D support to premake myself, but = that&#39;s wonderful news. I&#39;ll add support for VisualD if it is not al= ready done.<div>GDC is also important. Great news! :)<br><br><div class=3D"= gmail_quote"> On 7 December 2011 21:56, Jens Mueller <span dir=3D"ltr">&lt;<a href=3D"mai= lto:jens.k.mueller gmx.de">jens.k.mueller gmx.de</a>&gt;</span> wrote:<br><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> <div class=3D"HOEnZb"><div class=3D"h5">Andrew Gough wrote:<br> &gt; On Tue, 06 Dec 2011 18:14:25 +0000<br> &gt; Russel Winder &lt;<a href=3D"mailto:russel russel.org.uk">russel russe= l.org.uk</a>&gt; wrote:<br> &gt;<br> &gt; &gt; SCons is a Python-based build tool to replace Make and much of th= e<br> &gt; &gt; Autotools functionality. =C2=A0It has D support as part of the co= re. =C2=A0This<br> &gt; &gt; support is though in need of development.<br> &gt; &gt;<br> &gt; &gt; The new Mercurial/BitBucket infrastructure for developing SCons<b= r> &gt; &gt; (replacing the old Subversion/Tigris set up) is now in place, a n= ew<br> &gt; &gt; release 2.1.0 has been declared and everything is open for busine= ss<br> &gt; &gt; leading to a 2.2.0 release.<br> &gt; &gt;<br> &gt; &gt; I got my changes to support DMD 2 into this release :-)<br> &gt; &gt;<br> &gt; &gt; However, support for GDC, LDC, etc. is almost certainly still sad= ly<br> &gt; &gt; lacking, and indeed the support for DMD almost certainly needs a<= br> &gt; &gt; severe refactoring and most likely a rewrite.<br> &gt; &gt;<br> &gt; &gt; Rather than people having to work on a clone of SCons in order to= work<br> &gt; &gt; on the tool, I have created a separate Mercurial repository<br> &gt; &gt; (<a href=3D"https://bitbucket.org/russel/scons_dmd_new" target=3D= "_blank">https://bitbucket.org/russel/scons_dmd_new</a>) as a development v= ersion<br> &gt; &gt; of just the tool. =C2=A0When a new version of this separate tool = is<br> &gt; &gt; declared I create a pull request for the SCons mainline to get th= e<br> &gt; &gt; new version in the next version of SCons.<br> &gt; &gt;<br> &gt; &gt; Is anyone else other than me interested in using SCons as a build= tool<br> &gt; &gt; with D code? =C2=A0If there is, perhaps we can collaborate in som= e way to<br> &gt; &gt; progress SCons support for all the various realizations of D?<br> &gt; &gt;<br> &gt;<br> &gt; I think the build tool question is in need of the same level of high<b= r> &gt; level design and support that Steve Teale is working on for<br> &gt; std.database/std.sql.<br> &gt;<br> &gt; It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS<br=

<br> &gt; support to premake.<br> <br> </div></div>Where do I find your changes for premake?<br> <div class=3D"im"><br> &gt; Would it be a good idea to thrash out the arguments for/against a<br> &gt; particular tool, and build/support just one? =C2=A0The community doesn= &#39;t<br> &gt; seem big enough to be so fragmented. =C2=A0Java has Ant, Scala has sbt= =C2=A0-<br> &gt; surely D should have a canonical build tool?<br> <br> </div>I&#39;m unsure whether D needs its own configuration/build tool. It<b= r> definitely needs a package manager.<br> <br> For building there are different options but usually it&#39;s make. Most<br=

does both building and configuring. Just want to say that you can have<br> different tools for these jobs or single one.<br> Jacob&#39;s build tool looks good but I wonder what are the major<br> improvements over e.g. make (portability is an issue with make; maybe<br> simplicity).<br> <br> For configuring there are some options and so far none of them is<br> preferred by a majority. Different people weigh different aspects<br> differently. But it seems people are moving away from configure scripts.<br=

As Russell already said, several build/configuration tools are used and<br> there is no clear winner in general. So I think it&#39;s very nice that you= <br> have added support for D to premake. So we then have SCons (build and<br> configuration), CMake (configuration and several build tools via<br> generators), rdmd (can generate dependencies for Makefile), Jacob as a<br> build tool and there are several others specifically for D and premake.<br> <br> I&#39;m not sure about the state of each of these. But SCons and CMake work= <br> with dmd (both do configuration). premake is also configuration.<br> Regarding build tools I wonder how important they are. make works fairly<br=

<span class=3D"HOEnZb"><font color=3D"#888888"><br> Jens<br> </font></span></blockquote></div><br></div> --0016367f97ceb6e5eb04b3868c7a--
Dec 07 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 7 Dec 2011 22:39:34 +0200
Manu <turkeyman gmail.com> wrote:

 premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.

Didn't hear about premake before...how does it compare with e.g. Cmake? Anything like Cpack available for it? Sincerely, Gour --=20 As the ignorant perform their duties with attachment to results,=20 the learned may similarly act, but without attachment, for the=20 sake of leading people on the right path. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 07 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu <turkeyman gmail.com> wrote:
 
 premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.

Didn't hear about premake before...how does it compare with e.g. Cmake?

The nice thing about premake is that it is build using Lua. So you have a full language at your disposal. CMake's configuration language is not that nice or at least it takes time to get used to it. premake only concerns itself with configuring. Which I think is nice. But it has nothing similar to CMake's find_package last time I checked.
 Anything like Cpack available for it?

As far as I know no. Jens
Dec 07 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 7 Dec 2011 23:31:10 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 The nice thing about premake is that it is build using Lua. So you
 have a full language at your disposal.=20

Heh, that much I could see quickly...Something like Scons/Waf...
 CMake's configuration language is not that nice or at least it takes
 time to get used to it.=20

Well, although it's considered ugly by many, it can build stuff like KDE which means: good-enough, right?
 premake only concerns itself with configuring. Which I think is nice.
 But it has nothing similar to CMake's find_package last time I
 checked.

OK. I'll take a look, but Cmake seems to be really robust and supports *many* platforms.
 Anything like Cpack available for it?

As far as I know no.

Thanks...I still have to finish some web-stuff, then I'm going to tackle cmaked2...Asked on the mailing list about more details, but no reply...I'm not sure about testing suite which cmaked2 is supposed to pass. Sincerely, Gour --=20 Bewildered by the modes of material nature, the ignorant fully=20 engage themselves in material activities and become attached. But=20 the wise should not unsettle them, although these duties are inferior=20 due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 07 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d04083f4b8bf1c304b390453a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 8, 2011 at 1:06 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-12-07 23:31, Jens Mueller wrote:

 Gour wrote:

 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu<turkeyman gmail.com>  wrote:

  premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.

Didn't hear about premake before...how does it compare with e.g. Cmake?

The nice thing about premake is that it is build using Lua. So you have a full language at your disposal. CMake's configuration language is not that nice or at least it takes time to get used to it. premake only concerns itself with configuring. Which I think is nice. But it has nothing similar to CMake's find_package last time I checked.

Is Lua an external dependency or compiled into the executable? -- /Jacob Carlborg

It's built in. Premake is distributed as a single executable on all platforms. --f46d04083f4b8bf1c304b390453a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 8, 2011 at 1:06 AM, Jacob Carlborg <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:doob me.com">doob me.com</a>&gt;</span> wrote:<br><div class=3D= "gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> On 2011-12-07 23:31, Jens Mueller wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> Gour wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Wed, 7 Dec 2011 22:39:34 +0200<br> Manu&lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blank">turkeyman = gmail.com</a>&gt; =A0wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> premake supports D? I was planning to add D support to premake<br> myself, but that&#39;s wonderful news. I&#39;ll add support for VisualD if = it<br> is not already done.<br> </blockquote> <br> Didn&#39;t hear about premake before...how does it compare with e.g. Cmake?= <br> </blockquote> <br></div><div class=3D"im"> The nice thing about premake is that it is build using Lua. So you have<br>= </div> a full language at your disposal. CMake&#39;s configuration language is not= <br> that nice or at least it takes time to get used to it. premake only<div cla= ss=3D"im"><br> concerns itself with configuring. Which I think is nice. But it has<br> nothing similar to CMake&#39;s find_package last time I checked.<br> </div></blockquote> <br> Is Lua an external dependency or compiled into the executable?<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><div>It&#39;s built in. =A0Premake is = distributed as a single executable on all platforms.</div> --f46d04083f4b8bf1c304b390453a--
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
On Wed, 7 Dec 2011 20:56:17 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 Andrew Gough wrote:
 On Tue, 06 Dec 2011 18:14:25 +0000
 Russel Winder <russel russel.org.uk> wrote:
 
 SCons is a Python-based build tool to replace Make and much of the
 Autotools functionality.  It has D support as part of the core.
 This support is though in need of development.
 
 The new Mercurial/BitBucket infrastructure for developing SCons
 (replacing the old Subversion/Tigris set up) is now in place, a
 new release 2.1.0 has been declared and everything is open for
 business leading to a 2.2.0 release.
 
 I got my changes to support DMD 2 into this release :-)
 
 However, support for GDC, LDC, etc. is almost certainly still
 sadly lacking, and indeed the support for DMD almost certainly
 needs a severe refactoring and most likely a rewrite.
 
 Rather than people having to work on a clone of SCons in order to
 work on the tool, I have created a separate Mercurial repository
 (https://bitbucket.org/russel/scons_dmd_new) as a development
 version of just the tool.  When a new version of this separate
 tool is declared I create a pull request for the SCons mainline
 to get the new version in the next version of SCons.
 
 Is anyone else other than me interested in using SCons as a build
 tool with D code?  If there is, perhaps we can collaborate in
 some way to progress SCons support for all the various
 realizations of D?
 

I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake.

Where do I find your changes for premake?

https://bitbucket.org/goughy/premake-dev-d
 
 Would it be a good idea to thrash out the arguments for/against a
 particular tool, and build/support just one?  The community doesn't
 seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
 surely D should have a canonical build tool?

I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens

The reasons I chose premake were primarily: 1. No external dependencies (lua embedded in an executable) 2. Simple configuration 3. Cross platform 4. Generates native build scripts: make, VS, Code::Blocks etc etc I have to point out that I have only added DMD+make support as that is all I needed at the time, but have plans (who doesn't :-D) to add support for LDC, GDC, and other build chains. -- Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 07 Dec 2011 14:03:02 +0000
Russel Winder <russel russel.org.uk> wrote:

 On Wed, 2011-12-07 at 22:00 +1100, Andrew Gough wrote:
 [...]
 I'm suggesting that the current multi-pronged approach to providing
 a workable build system is hampered by the multitude of directions
 and could benefit from some initial discussion, consensus and
 design.

OK. It is a valid point, effort is being diluted. On the other hand various people prefer different systems, so I am not sure there is any constructive point in dictating the "one true build system". If there were one that gained a majority support votes then it could concentrate available effort. =20 [...]
 I agree that it would be good to use a tool with support for
 multiple languages & platforms.  I was trying to point out that the
 multitude of options is potentially harmful.

Or an opportunity? =20

Maybe.
 D is trying to supplant C, C++, Fortran and Python.  D should
 therefore be buildable with the same tools that people use with these
 languages in order to provide the lowest possible barrier to entry to
 D of C, C++, Fortran and Python programmers.  Not having to change
 build system but simply to add to their current build system makes
 transition easier.
=20

 [...]
 Simple Ant scripts are easy, but XML is a very bad choice for a
 build system IMO=20

XML was an interesting choice originally, but has been perverted beyond sanity in the Ant context. This is why I wrote Gant -- use all the Ant tasks but not from the XML interpreter but from Groovy scripts. The idea cannot have been all bad as it inspired Hans Dockter to create Gradle, and the Apache folk forked Gant to create the Groovy frontend to Ant. =20 [...]
=20
 Not really what I was suggesting - I was hoping to discuss
 consolidating effort around a small set of tools, rather than the
 current state.

I fully appreciate the idea is to focus effort so as to avoid dilution. With the effort available it is a good idea. I am just not convinced creating new tools from scratch is the right approach. =20 [...]
 Do we work with a build framework that exists and already allows
 serious build using D; or

Possibly. =20
 do we start from scratch with a new build framework that no-one
 can use till something is ready?

Possibly (if necessary) =20 I thought it important to have a discussion first to determine the requirements and use cases, and concentrate effort rather than disperse it.

Having a full and frank exchange of views is an excellent move. As long as everyone stays friends! =20 Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen, Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the overall effect of a "focused on D" build tool, whether build from scratch or over another framework. Specialist per language build tools lead to a ghettoization. Even 5 mins looking at the Rake, sbt and Leiningen situations make this abundantly clear. Which is sad as there are many good things about all of them. =20 If there effort to start from scratch with D to create the replacement for Make, CMake, Autotools, as a general build framework, that is a different issue. But this is a big undertaking requiring DAGs, C scanners, C++ scanners, Fortran scanners, LaTeX scanners, etc., not to mention tool finders and toolchain builders.

I actually think its unnecessary to start from scratch, but am interested in other's opinions.
=20
 My current prejudice is that SCons, Waf and CMake already have almost
 all of this stuff already in place, so it is an incremental step to
 make sure they work well with D (*).
=20

I agree - my preference is for a build configuration tool like CMake or premake. They already do a lot of the heavy lifting and can potentially support polyglot builds. I think that may be important in D's future considering Deimos. --=20 Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
On Wed, 7 Dec 2011 22:39:34 +0200
Manu <turkeyman gmail.com> wrote:

 premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.
 GDC is also important. Great news! :)
 

I'd be happy to continue - I simply got my fork working for DMD+make and just use it locally. It was reviewed by premake's author and he seemed happy with the implementation, but I haven't gotten around to providing an upstream patch. If there is enough interest, I can fix up some loose ends and try and get the ball rolling again... -- Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 07 Dec 2011 14:03:02 +0000
Russel Winder <russel russel.org.uk> wrote:

 On Wed, 2011-12-07 at 22:00 +1100, Andrew Gough wrote:
 [...]
 I'm suggesting that the current multi-pronged approach to providing
 a workable build system is hampered by the multitude of directions
 and could benefit from some initial discussion, consensus and
 design.

OK. It is a valid point, effort is being diluted. On the other hand various people prefer different systems, so I am not sure there is any constructive point in dictating the "one true build system". If there were one that gained a majority support votes then it could concentrate available effort. =20 [...]
 I agree that it would be good to use a tool with support for
 multiple languages & platforms.  I was trying to point out that the
 multitude of options is potentially harmful.

Or an opportunity? =20

Maybe.
 D is trying to supplant C, C++, Fortran and Python.  D should
 therefore be buildable with the same tools that people use with these
 languages in order to provide the lowest possible barrier to entry to
 D of C, C++, Fortran and Python programmers.  Not having to change
 build system but simply to add to their current build system makes
 transition easier.
=20

 [...]
 Simple Ant scripts are easy, but XML is a very bad choice for a
 build system IMO=20

XML was an interesting choice originally, but has been perverted beyond sanity in the Ant context. This is why I wrote Gant -- use all the Ant tasks but not from the XML interpreter but from Groovy scripts. The idea cannot have been all bad as it inspired Hans Dockter to create Gradle, and the Apache folk forked Gant to create the Groovy frontend to Ant. =20 [...]
=20
 Not really what I was suggesting - I was hoping to discuss
 consolidating effort around a small set of tools, rather than the
 current state.

I fully appreciate the idea is to focus effort so as to avoid dilution. With the effort available it is a good idea. I am just not convinced creating new tools from scratch is the right approach. =20 [...]
 Do we work with a build framework that exists and already allows
 serious build using D; or

Possibly. =20
 do we start from scratch with a new build framework that no-one
 can use till something is ready?

Possibly (if necessary) =20 I thought it important to have a discussion first to determine the requirements and use cases, and concentrate effort rather than disperse it.

Having a full and frank exchange of views is an excellent move. As long as everyone stays friends! =20 Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen, Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the overall effect of a "focused on D" build tool, whether build from scratch or over another framework. Specialist per language build tools lead to a ghettoization. Even 5 mins looking at the Rake, sbt and Leiningen situations make this abundantly clear. Which is sad as there are many good things about all of them. =20 If there effort to start from scratch with D to create the replacement for Make, CMake, Autotools, as a general build framework, that is a different issue. But this is a big undertaking requiring DAGs, C scanners, C++ scanners, Fortran scanners, LaTeX scanners, etc., not to mention tool finders and toolchain builders.

I actually think its unnecessary to start from scratch, but am interested in other's opinions.
=20
 My current prejudice is that SCons, Waf and CMake already have almost
 all of this stuff already in place, so it is an incremental step to
 make sure they work well with D (*).
=20

I agree - my preference is for a build configuration tool like CMake or premake. They already do a lot of the heavy lifting and can potentially support polyglot builds. I think that may be important in D's future considering Deimos. --=20 Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
On Thu, 08 Dec 2011 11:23:18 +0100
Jacob Carlborg <doob me.com> wrote:

 On 2011-12-08 10:13, Andrew Gough wrote:
 The reasons I chose premake were primarily:

 1. No external dependencies (lua embedded in an executable)
 2. Simple configuration
 3. Cross platform
 4. Generates native build scripts: make, VS, Code::Blocks etc etc

 I have to point out that I have only added DMD+make support as that
 is all I needed at the time, but have plans (who doesn't :-D) to add
 support for LDC, GDC, and other build chains.

So it depends on external build tools. I don't like that. I guess it could have an option to generate makefiles or similar but by default it should be able to build on its own.

No problem. I disagree and think that a cross platform build generator that leverages native build tools is a better approach and provides more flexibility in the long run. Particularly for Windows VS users or people tied to an IDE - configuration that generates to various IDE build scripts keeps those devs happier IMO -- Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51962e3099d4304b394ce4b
Content-Type: text/plain; charset=UTF-8

On 8 December 2011 15:27, Mike Parker <aldacron gmail.com> wrote:

 On 12/8/2011 6:29 PM, Andrew Gough wrote:

 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu<turkeyman gmail.com>  wrote:

  premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.
 GDC is also important. Great news! :)

and just use it locally. It was reviewed by premake's author and he seemed happy with the implementation, but I haven't gotten around to providing an upstream patch. If there is enough interest, I can fix up some loose ends and try and get the ball rolling again...


+10 I'd also be interested in forking your fork to add some stuff too (visual studio support). I also have a pile of local changes to support various consoles to my local premake, which I haven't tried to push upstream. This is for C/C++, but I'd love to add support for the same consoles via GDC. --bcaec51962e3099d4304b394ce4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 December 2011 15:27, Mike Parker <span dir= =3D"ltr">&lt;<a href=3D"mailto:aldacron gmail.com">aldacron gmail.com</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"HOEnZb"><div class=3D"h5">On 12/8/2011 6:29 PM, Andrew Gough = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Wed, 7 Dec 2011 22:39:34 +0200<br> Manu&lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blank">turkeyman = gmail.com</a>&gt; =C2=A0wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> premake supports D? I was planning to add D support to premake<br> myself, but that&#39;s wonderful news. I&#39;ll add support for VisualD if = it<br> is not already done.<br> GDC is also important. Great news! :)<br> <br> </blockquote> <br> I&#39;d be happy to continue - I simply got my fork working for DMD+make<br=

he<br> seemed happy with the implementation, but I haven&#39;t gotten around to<br=

<br> If there is enough interest, I can fix up some loose ends and try and<br> get the ball rolling again...<br> <br> </blockquote> <br></div></div> +1<br></blockquote><div>=C2=A0</div></div>+10<div><br></div><div>I&#39;d al= so be interested in forking your fork to add some stuff too (visual studio = support).</div><div>I also have a pile of local changes to support various = consoles to my local premake, which I haven&#39;t tried to push upstream. T= his is for C/C++, but I&#39;d love to add support for the same consoles via= GDC.</div> <div><br></div> --bcaec51962e3099d4304b394ce4b--
Dec 08 2011
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
 No problem.  I disagree and think that a cross platform build 
 generator
 that leverages native build tools is a better approach and 
 provides
 more flexibility in the long run. Particularly for Windows VS 
 users or
 people tied to an IDE - configuration that generates to various 
 IDE
 build scripts keeps those devs happier IMO

Well, native projects do make developers happier, but if the tool can't build on its own, there's no reason to use it, if make just works. premake will be a burden of an extra level to go through.
Dec 08 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 8 Dec 2011 20:13:29 +1100
Andrew Gough <andrew goughy.org> wrote:

 I have to point out that I have only added DMD+make support as that is
 all I needed at the time, but have plans (who doesn't :-D) to add
 support for LDC, GDC, and other build chains.

Does premake support building SWIG extensions? Sincerely, Gour --=20 Those who are on this path are resolute in purpose,=20 and their aim is one. O beloved child of the Kurus,=20 the intelligence of those who are irresolute is many-branched. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 08 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 8 Dec 2011 20:29:20 +1100
Andrew Gough <andrew goughy.org> wrote:

 If there is enough interest, I can fix up some loose ends and try and
 get the ball rolling again...

+1 --=20 In this endeavor there is no loss or diminution,=20 and a little advancement on this path can protect=20 one from the most dangerous type of fear. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
On Thu, 08 Dec 2011 16:19:27 +0100
"Kagamin" <spam here.lot> wrote:

 No problem.  I disagree and think that a cross platform build 
 generator
 that leverages native build tools is a better approach and 
 provides
 more flexibility in the long run. Particularly for Windows VS 
 users or
 people tied to an IDE - configuration that generates to various 
 IDE
 build scripts keeps those devs happier IMO

Well, native projects do make developers happier, but if the tool can't build on its own, there's no reason to use it, if make just works. premake will be a burden of an extra level to go through.

That's the whole point, though. A build configuration allows you to target a number of native build tools - not just make. Premake4 supports: codeblocks Generate Code::Blocks project files codelite Generate CodeLite project files gmake Generate GNU makefiles for POSIX, MinGW, and Cygwin vs2002 Generate Microsoft Visual Studio 2002 project files vs2003 Generate Microsoft Visual Studio 2003 project files vs2005 Generate Microsoft Visual Studio 2005 project files vs2008 Generate Microsoft Visual Studio 2008 project files vs2010 Generate Visual Studio 2010 project files xcode3 Generate Apple Xcode 3 project files (experimental) xcode4 Generate Apple Xcode 4 project files (experimental) CMake supports: Borland Makefiles MSYS Makefiles MinGW Makefiles NMake Makefiles NMake Makefiles JOM Unix Makefiles Visual Studio 10 Visual Studio 10 IA64 Visual Studio 10 Win64 Visual Studio 11 Visual Studio 11 Win64 Visual Studio 6 Visual Studio 7 Visual Studio 7 .NET 2003 Visual Studio 8 2005 Visual Studio 8 2005 Win64 Visual Studio 9 2008 Visual Studio 9 2008 IA64 Visual Studio 9 2008 Win64 Watcom WMake CodeBlocks - MinGW Makefiles CodeBlocks - NMake Makefiles CodeBlocks - Unix Makefiles Eclipse CDT4 - MinGW Makefiles Eclipse CDT4 - NMake Makefiles Eclipse CDT4 - Unix Makefiles -- Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
On Thu, 8 Dec 2011 15:39:59 +0200
Manu <turkeyman gmail.com> wrote:

 On 8 December 2011 15:27, Mike Parker <aldacron gmail.com> wrote:
 
 On 12/8/2011 6:29 PM, Andrew Gough wrote:

 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu<turkeyman gmail.com>  wrote:

  premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD
 if it is not already done.
 GDC is also important. Great news! :)

DMD+make and just use it locally. It was reviewed by premake's author and he seemed happy with the implementation, but I haven't gotten around to providing an upstream patch. If there is enough interest, I can fix up some loose ends and try and get the ball rolling again...


+10 I'd also be interested in forking your fork to add some stuff too (visual studio support). I also have a pile of local changes to support various consoles to my local premake, which I haven't tried to push upstream. This is for C/C++, but I'd love to add support for the same consoles via GDC.

Go for it. I think the more complete we can get premake in this area the better. -- Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 08 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 09 Dec 2011 09:28:52 +0900
Mike Parker <aldacron gmail.com> wrote:

 Not out of the box, but it would be trivial to add as a custom Action.

Thank you. All in all, premake looks very interesting & clean. Sincerely, Gour --=20 Bewildered by the modes of material nature, the ignorant fully=20 engage themselves in material activities and become attached. But=20 the wise should not unsettle them, although these duties are inferior=20 due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 08 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 8 Dec 2011 20:29:20 +1100
Andrew Gough <andrew goughy.org> wrote:

 If there is enough interest, I can fix up some loose ends and try and
 get the ball rolling again...

I got reply from premake developer and he told me that D support in only in 'experimental' branch. Will you try to push it upstream? Sincerely, Gour --=20 You have a right to perform your prescribed duty,=20 but you are not entitled to the fruits of action.=20 Never consider yourself the cause of the results=20 of your activities, and never be attached to not doing your duty. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 09 2011
prev sibling next sibling parent Andrew Gough <andrew goughy.org> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 9 Dec 2011 13:28:45 +0100
Gour <gour atmarama.net> wrote:

 On Thu, 8 Dec 2011 20:29:20 +1100
 Andrew Gough <andrew goughy.org> wrote:
=20
 If there is enough interest, I can fix up some loose ends and try
 and get the ball rolling again...

I got reply from premake developer and he told me that D support in only in 'experimental' branch. Will you try to push it upstream? =20 =20 Sincerely, Gour =20

Yep - as I say its only preliminary. At the moment it builds my projects ok, but is probably not ready for production use, for instance, arbitrary build flags are not passed through. I'll clean it up, commit and open a patch for review and inclusion upstream. That'll take a few days, though. FYI: here is the full premake definition for a (small) project of mine... solution "http4d" configurations { "debug" } configuration { "debug", "gmake" } buildoptions { "-gc" } -- NB: this is not operational yet project "http4d" kind "StaticLib" language "D" files { "**.d" } excludes { "main.d" } configuration "debug64" defines { "debug" } platforms "x64" flags { "Symbols", "ExtraWarnings" } project "test" kind "ConsoleApp" language "D" files { "main.d" } links { "libhttp4d.a" } configuration "debug64" defines "debug" platforms "x64" flags { "Symbols", "ExtraWarnings", "Test" } --=20 Andrew Gough M: 0408 596 656 andrew goughy.org
Dec 09 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 10 Dec 2011 11:25:18 +1100
Andrew Gough <andrew goughy.org> wrote:

 Yep - as I say its only preliminary.  At the moment it builds my
 projects ok, but is probably not ready for production use, for
 instance, arbitrary build flags are not passed through.

OK.
 I'll clean it up, commit and open a patch for review and inclusion
 upstream.  That'll take a few days, though.

Thanks a lot.
 FYI: here is the full premake definition for a (small) project of
 mine...

[...] I must admit that it really looks nice & clean. Sincerely Gour --=20 =46rom anger, complete delusion arises, and from delusion=20 bewilderment of memory. When memory is bewildered,=20 intelligence is lost, and when intelligence is lost=20 one falls down again into the material pool. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 10 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001636832444a51c5c04b3bc08d1
Content-Type: text/plain; charset=UTF-8

 Yep - as I say its only preliminary.  At the moment it builds my
 projects ok, but is probably not ready for production use, for
 instance, arbitrary build flags are not passed through.

 I'll clean it up, commit and open a patch for review and inclusion
 upstream.  That'll take a few days, though.

Nice! Looking forward to it! :) --001636832444a51c5c04b3bc08d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im= ">Yep - as I say its only preliminary. =C2=A0At the moment it builds my</di= v> projects ok, but is probably not ready for production use, for<br> instance, arbitrary build flags are not passed through.<br> <br> I&#39;ll clean it up, commit and open a patch for review and inclusion<br> upstream. =C2=A0That&#39;ll take a few days, though.<br></blockquote><div><= br></div><div><br></div><div>Nice! Looking forward to it! :)=C2=A0</div></d= iv> --001636832444a51c5c04b3bc08d1--
Dec 10 2011
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
--14dae9399d5f2316a204b5984236
Content-Type: text/plain; charset=ISO-8859-1

Premake has good support for cross compilation - Which makes it possible to
use it to build executables for game consoles for instance. CMake can't
really do this (with some ugly hacks you can get close). On the other hand
Premake doesn't handle installation on a Linux/BSD system really at all -
It's hard to reccomend it for doing normal desktop application development
on these platforms.

On Thu, Dec 8, 2011 at 8:09 AM, Gour <gour atmarama.net> wrote:

 On Wed, 7 Dec 2011 22:39:34 +0200
 Manu <turkeyman gmail.com> wrote:

 premake supports D? I was planning to add D support to premake
 myself, but that's wonderful news. I'll add support for VisualD if it
 is not already done.

Didn't hear about premake before...how does it compare with e.g. Cmake? Anything like Cpack available for it? Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

--14dae9399d5f2316a204b5984236 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Premake has good support for cross compilation - Which makes it possible to= use it to build executables for game consoles for instance. CMake can&#39;= t really do this (with some ugly hacks you can get close). On the other han= d Premake doesn&#39;t handle installation on a Linux/BSD system really at a= ll - It&#39;s hard to reccomend it for doing normal desktop application dev= elopment on these platforms.<br> <br><div class=3D"gmail_quote">On Thu, Dec 8, 2011 at 8:09 AM, Gour <span d= ir=3D"ltr">&lt;<a href=3D"mailto:gour atmarama.net">gour atmarama.net</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Wed, 7 Dec 2011 22:39:34 +0200<br> Manu &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt;= wrote:<br> <br> &gt; premake supports D? I was planning to add D support to premake<br> &gt; myself, but that&#39;s wonderful news. I&#39;ll add support for Visual= D if it<br> &gt; is not already done.<br> <br> </div>Didn&#39;t hear about premake before...how does it compare with e.g. = Cmake?<br> <br> Anything like Cpack available for it?<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <br> Sincerely,<br> Gour<br> <br> <br> --<br> As the ignorant perform their duties with attachment to results,<br> the learned may similarly act, but without attachment, for the<br> sake of leading people on the right path.<br> <br> <a href=3D"http://atmarama.net" target=3D"_blank">http://atmarama.net</a> |= Hlapicina (Croatia) | GPG: 52B5C810<br> </div></div></blockquote></div><br> --14dae9399d5f2316a204b5984236--
Jan 02 2012
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 3 Jan 2012 14:37:36 +1000
Danni Coy <danni.coy gmail.com> wrote:

 Premake has good support for cross compilation - Which makes it
 possible to use it to build executables for game consoles for
 instance. CMake can't really do this (with some ugly hacks you can

 On the other hand Premake doesn't handle installation on
 a Linux/BSD system really at all - It's hard to reccomend it for
 doing normal desktop application development on these platforms.

What do you mean? Premake is meta tool and the build is delegated to other native tools, afaict, or do you miss 'make install' target? Sincerely, Gour --=20 Those who are on this path are resolute in purpose,=20 and their aim is one. O beloved child of the Kurus,=20 the intelligence of those who are irresolute is many-branched. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 02 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30051342c20f6804b59b4389
Content-Type: text/plain; charset=UTF-8

Premake just runs a lua script. You can theoretically create any
installation script you like... although you would need to: premake
install, rather than: make install

On 3 January 2012 09:21, Gour <gour atmarama.net> wrote:

 On Tue, 3 Jan 2012 14:37:36 +1000
 Danni Coy <danni.coy gmail.com> wrote:

 Premake has good support for cross compilation - Which makes it
 possible to use it to build executables for game consoles for
 instance. CMake can't really do this (with some ugly hacks you can

 On the other hand Premake doesn't handle installation on
 a Linux/BSD system really at all - It's hard to reccomend it for
 doing normal desktop application development on these platforms.

What do you mean? Premake is meta tool and the build is delegated to other native tools, afaict, or do you miss 'make install' target? Sincerely, Gour -- Those who are on this path are resolute in purpose, and their aim is one. O beloved child of the Kurus, the intelligence of those who are irresolute is many-branched. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

--20cf30051342c20f6804b59b4389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Premake just runs a lua script. You can theoretically create any installati= on script you like... although you would need to: premake install, rather t= han: make install<br><br><div class=3D"gmail_quote">On 3 January 2012 09:21= , Gour <span dir=3D"ltr">&lt;<a href=3D"mailto:gour atmarama.net">gour atma= rama.net</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, 3 Jan 2012 14:37:3= 6 +1000<br> Danni Coy &lt;<a href=3D"mailto:danni.coy gmail.com">danni.coy gmail.com</a=
&gt; wrote:<br>

&gt; Premake has good support for cross compilation - Which makes it<br> &gt; possible to use it to build executables for game consoles for<br> &gt; instance. CMake can&#39;t really do this (with some ugly hacks you can= <br> <br> </div><div class=3D"im">&gt; On the other hand Premake doesn&#39;t handle i= nstallation on<br> &gt; a Linux/BSD system really at all - It&#39;s hard to reccomend it for<b= r> &gt; doing normal desktop application development on these platforms.<br> <br> </div>What do you mean?<br> <br> Premake is meta tool and the build is delegated to other native tools,<br> afaict, or do you miss &#39;make install&#39; target?<br> <div class=3D"im HOEnZb"><br> <br> Sincerely,<br> Gour<br> <br> --<br> Those who are on this path are resolute in purpose,<br> and their aim is one. O beloved child of the Kurus,<br> the intelligence of those who are irresolute is many-branched.<br> <br> </div><div class=3D"HOEnZb"><div class=3D"h5"><a href=3D"http://atmarama.ne= t" target=3D"_blank">http://atmarama.net</a> | Hlapicina (Croatia) | GPG: 5= 2B5C810<br> </div></div></blockquote></div><br> --20cf30051342c20f6804b59b4389--
Jan 03 2012
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
--f46d04440066889c4c04b59d4b97
Content-Type: text/plain; charset=ISO-8859-1

You probably can but it doesn't come free out of the box like every other
build system I have tried on Linux. I have gotten around the problem before
(when I packaged libFuji) but it was a lot more work than using CMake.

On Tue, Jan 3, 2012 at 6:12 PM, Manu <turkeyman gmail.com> wrote:

 Premake just runs a lua script. You can theoretically create any
 installation script you like... although you would need to: premake
 install, rather than: make install


 On 3 January 2012 09:21, Gour <gour atmarama.net> wrote:

 On Tue, 3 Jan 2012 14:37:36 +1000
 Danni Coy <danni.coy gmail.com> wrote:

 Premake has good support for cross compilation - Which makes it
 possible to use it to build executables for game consoles for
 instance. CMake can't really do this (with some ugly hacks you can

 On the other hand Premake doesn't handle installation on
 a Linux/BSD system really at all - It's hard to reccomend it for
 doing normal desktop application development on these platforms.

What do you mean? Premake is meta tool and the build is delegated to other native tools, afaict, or do you miss 'make install' target? Sincerely, Gour -- Those who are on this path are resolute in purpose, and their aim is one. O beloved child of the Kurus, the intelligence of those who are irresolute is many-branched. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


--f46d04440066889c4c04b59d4b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You probably can but it doesn&#39;t come free out of the box like every oth= er build system I have tried on Linux. I have gotten around the problem bef= ore (when I packaged libFuji) but it was a lot more work than using CMake.= =A0<br> <br><div class=3D"gmail_quote">On Tue, Jan 3, 2012 at 6:12 PM, Manu <span d= ir=3D"ltr">&lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail.com</= a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Premake just runs a lua script. You can theoretically create any installati= on script you like... although you would need to: premake install, rather t= han: make install<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class= =3D"gmail_quote"> On 3 January 2012 09:21, Gour <span dir=3D"ltr">&lt;<a href=3D"mailto:gour = atmarama.net" target=3D"_blank">gour atmarama.net</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div>On Tue, 3 Jan 2012 14:37:36 +1000<br> Danni Coy &lt;<a href=3D"mailto:danni.coy gmail.com" target=3D"_blank">dann= i.coy gmail.com</a>&gt; wrote:<br> <br> &gt; Premake has good support for cross compilation - Which makes it<br> &gt; possible to use it to build executables for game consoles for<br> &gt; instance. CMake can&#39;t really do this (with some ugly hacks you can= <br> <br> </div><div>&gt; On the other hand Premake doesn&#39;t handle installation o= n<br> &gt; a Linux/BSD system really at all - It&#39;s hard to reccomend it for<b= r> &gt; doing normal desktop application development on these platforms.<br> <br> </div>What do you mean?<br> <br> Premake is meta tool and the build is delegated to other native tools,<br> afaict, or do you miss &#39;make install&#39; target?<br> <div><br> <br> Sincerely,<br> Gour<br> <br> --<br> Those who are on this path are resolute in purpose,<br> and their aim is one. O beloved child of the Kurus,<br> the intelligence of those who are irresolute is many-branched.<br> <br> </div><div><div><a href=3D"http://atmarama.net" target=3D"_blank">http://at= marama.net</a> | Hlapicina (Croatia) | GPG: 52B5C810<br> </div></div></blockquote></div><br> </div></div></blockquote></div><br> --f46d04440066889c4c04b59d4b97--
Jan 03 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235452e96013531d04bb95161c
Content-Type: text/plain; charset=UTF-8

On 7 December 2011 11:27, Andrew Gough <andrew goughy.org> wrote:

 It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS
 (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D
 support to premake.

Can I see your changes anywhere? I have a premake based project infrastructure that I'd like to incorporate some D code into. --00235452e96013531d04bb95161c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 December 2011 11:27, Andrew Gough <span dir= =3D"ltr">&lt;<a href=3D"mailto:andrew goughy.org">andrew goughy.org</a>&gt;= </span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">It seems there is SCons support (python), CMake, Orbit (R= uby), DSSS<br></div> (D1 only?), xfbuild, dake, rdmd options - I&#39;ve added preliminary D<br> support to premake.<br></blockquote><div><br></div><div>Can I see your chan= ges anywhere? I have a premake based project infrastructure that I&#39;d li= ke to incorporate some D code into.</div></div> --00235452e96013531d04bb95161c--
Mar 19 2012
prev sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Mon, 19 Mar 2012 11:21:41 +0200
Manu <turkeyman gmail.com> wrote:

 Can I see your changes anywhere? I have a premake based project
 infrastructure that I'd like to incorporate some D code into.

https://bitbucket.org/goughy/premake-dev-d Sincerely, Gour --=20 One is understood to be in full knowledge whose every endeavor=20 is devoid of desire for sense gratification. He is said by sages=20 to be a worker for whom the reactions of work have been burned=20 up by the fire of perfect knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Mar 19 2012