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