digitalmars.D - SCons support for D

Russel Winder (30/30) Dec 06 2011 SCons is a Python-based build tool to replace Make and much of the

eles (4/7) Dec 06 2011 I am interested. SCons is my build tool of choice (for C/C++),a lthough
Andrew Gough (16/42) Dec 07 2011 I think the build tool question is in need of the same level of high

Russel Winder (47/57) Dec 07 2011 I am not sure I quite get that, sorry.

Andrew Gough (22/82) Dec 07 2011 I'm suggesting that the current multi-pronged approach to providing a

Russel Winder (56/81) Dec 07 2011 OK. It is a valid point, effort is being diluted. On the other hand

Jacob Carlborg (6/13) Dec 07 2011 Rake isn't targeted to a single language. It's just as make but with a
Andrew Gough (14/98) Dec 08 2011 Maybe.
Andrew Gough (14/98) Dec 08 2011 Maybe.

Jacob Carlborg (16/62) Dec 07 2011 What I see as the advantage of a new build system is that it can be

Russel Winder (24/42) Dec 07 2011 =20

Jacob Carlborg (11/40) Dec 07 2011 There are still cases when special flags are needed and how is the

Paulo Pinto (6/22) Dec 07 2011 There are still makefiles required.

Jacob Carlborg (4/26) Dec 07 2011 I see.

Gour (15/35) Dec 07 2011 Hmm...isn0t it too simplistic?

Jacob Carlborg (9/39) Dec 07 2011 Of course it should be possible to build more complex projects and have

Russel Winder (40/57) Dec 07 2011 =20

Jacob Carlborg (27/71) Dec 07 2011 Ok, sounds good. But I'm not sure if I like that you just have to invoke...
Jacob Carlborg (10/28) Dec 08 2011 If I understand everything correctly Scons uses Python for its build

Jacob Carlborg (4/38) Dec 07 2011 Orbit is a package manager and not a build tool.
Jens Mueller (25/66) Dec 07 2011 I'm unsure whether D needs its own configuration/build tool. It

Jacob Carlborg (6/29) Dec 07 2011 I want a simple portable build tool. DSSS was/is a good tool, but it's
Andrew Gough (15/92) Dec 08 2011 https://bitbucket.org/goughy/premake-dev-d

Jacob Carlborg (6/14) Dec 08 2011 So it depends on external build tools. I don't like that. I guess it

Andrew Gough (11/27) Dec 08 2011 No problem. I disagree and think that a cross platform build generator

Jacob Carlborg (4/27) Dec 08 2011 I don't agree.
Kagamin (3/12) Dec 08 2011 Well, native projects do make developers happier, but if the tool

Jacob Carlborg (4/12) Dec 08 2011 Make is a burden.
Andrew Gough (46/59) Dec 08 2011 That's the whole point, though. A build configuration allows you to

Mike Parker (4/92) Dec 08 2011 I've considered doing this several times in the past. Managing the
Gour (10/13) Dec 08 2011 Does premake support building SWIG extensions?

Mike Parker (2/10) Dec 08 2011 Not out of the box, but it would be trivial to add as a custom Action.

Gour (12/13) Dec 08 2011 Thank you.

Manu (5/71) Dec 07 2011 premake supports D? I was planning to add D support to premake myself, b...

Gour (11/14) Dec 07 2011 Didn't hear about premake before...how does it compare with e.g. Cmake?

Jens Mueller (8/17) Dec 07 2011 The nice thing about premake is that it is build using Lua. So you have

Gour (19/29) Dec 07 2011 Heh, that much I could see quickly...Something like Scons/Waf...
Jacob Carlborg (4/18) Dec 08 2011 Is Lua an external dependency or compiled into the executable?

Brad Anderson (3/27) Dec 08 2011 It's built in. Premake is distributed as a single executable on all

Jacob Carlborg (4/10) Dec 08 2011 That's good and I think that's how all build tools should do.

Danni Coy (7/21) Jan 02 2012 Premake has good support for cross compilation - Which makes it possible...

Gour (12/18) Jan 02 2012 What do you mean?

Manu (4/22) Jan 03 2012 Premake just runs a lua script. You can theoretically create any
Danni Coy (4/35) Jan 03 2012 You probably can but it doesn't come free out of the box like every othe...

Andrew Gough (12/17) Dec 08 2011 I'd be happy to continue - I simply got my fork working for DMD+make

Mike Parker (2/15) Dec 08 2011 +1

Manu (7/27) Dec 08 2011 +10

Andrew Gough (8/41) Dec 08 2011 Go for it. I think the more complete we can get premake in this area

Gour (8/10) Dec 08 2011 +1
Gour (12/14) Dec 09 2011 I got reply from premake developer and he told me that D support in only

Andrew Gough (35/48) Dec 09 2011 Yep - as I say its only preliminary. At the moment it builds my

Gour (14/21) Dec 10 2011 OK.
Manu (1/6) Dec 10 2011 Nice! Looking forward to it! :)

Nick Sabalausky (16/23) Dec 08 2011 xfbuild and rdmd are not really build managers. They're just frontends t...
Manu (3/6) Mar 19 2012 Can I see your changes anywhere? I have a premake based project

Gour (11/13) Mar 19 2012 https://bitbucket.org/goughy/premake-dev-d

Russel Winder <russel russel.org.uk> writes:

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

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

Andrew Gough <andrew goughy.org> writes:

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

Russel Winder <russel russel.org.uk> writes:

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

Andrew Gough <andrew goughy.org> writes:

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.

=20
 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.

=20
 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?

=20
 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

Russel Winder <russel russel.org.uk> writes:

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

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

=20
 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

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

Andrew Gough <andrew goughy.org> writes:

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.

=20
 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.

=20
 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

Agreed.

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

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

=20
 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

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

=20
 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.

=20
 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

Andrew Gough <andrew goughy.org> writes:

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.

=20
 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.

=20
 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

Agreed.

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

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

=20
 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

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

=20
 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.

=20
 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

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

Russel Winder <russel russel.org.uk> writes:

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

=20
 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=

=20
 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=

=20
 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

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

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

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

Gour <gour atmarama.net> writes:

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

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

Russel Winder <russel russel.org.uk> writes:

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=

=20
 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=

=20
 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

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

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

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

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

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

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

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

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

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

"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

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

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

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

Gour <gour atmarama.net> writes:

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

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

Gour <gour atmarama.net> writes:

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

Manu <turkeyman gmail.com> writes:

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

Dec 07 2011

Gour <gour atmarama.net> 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.

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

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

Gour <gour atmarama.net> writes:

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?

=20
 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

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

Brad Anderson <eco gnuk.net> writes:

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.

Dec 08 2011

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

Danni Coy <danni.coy gmail.com> writes:

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

Jan 02 2012

Gour <gour atmarama.net> writes:

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

Manu <turkeyman gmail.com> writes:

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

Jan 03 2012

Danni Coy <danni.coy gmail.com> writes:

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

Jan 03 2012

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

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

Manu <turkeyman gmail.com> writes:

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! :)

 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

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

Dec 08 2011

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! :)

 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

 
 +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

Gour <gour atmarama.net> writes:

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

Gour <gour atmarama.net> writes:

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

Andrew Gough <andrew goughy.org> writes:

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

=20
 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

Gour <gour atmarama.net> writes:

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

Manu <turkeyman gmail.com> writes:

 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! :)

Dec 10 2011

"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

Manu <turkeyman gmail.com> writes:

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.

Mar 19 2012

Gour <gour atmarama.net> writes:

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

D Programming

C/C++ Programming

Other

digitalmars.D - SCons support for D