Make [was Re: SCons and gdc]

[H. S. Teoh]

On Tue, Oct 30, 2012 at 12:19:46AM +0100, Rob T wrote:
[...]
> Scons is far too rigid with the assumptions it makes, and IMO some
> of the assumptions are plain wrong.
> 
> For example, building to a location out of the source tree has the
> obvious advantage that your source tree remains a source tree. I
> don't understand how anyone can consider this unusual or not
> necessary. If a source tree is to be a tree containing source code,
> then recursive scanning and building out of the tree is an essential
> requirement.
> 
> Scons however assumes that your source tree must be flat, and that
> your source tree must be polluted with build files.

I don't know where you got this assumption from, but it's plain wrong.
SCons supports out-of-source-tree builds. In fact, I have a project in
which I generate multiple builds from the same source tree (and I can
build *all* build variants in a single command, parallelized - something
that will cause make to keel over and die).

The only bug is that SCons assumes that the source tree and build
tree(s) must be under a common root, which may not be the case.
Nevertheless, even this is not a fatal problem, as you can just put your
SConstruct in the directory above the source tree, then you can build to
other subdirectories easily.


> >SCons depends only on Python. What are these other dependencies that
> >you speak of?
> 
> You are correct, only Python, which on a Linux system is normally
> installed by default. I was refering to the need to manually build
> scons from from a source repository in order to get latest D support.
> I know I'm in the bleeding edge zone when it comes to D, so a certain
> amount of hacking is needed, but I'd like to minimize it as much as
> possible.

This is just what one puts up with when working with bleeding edge
technology. If there weren't kinks in the works, it'd be mainstream
already.


[...]
> >As far as I am aware there are no D coded build frameworks that can
> >handle C, C++, Fortran, D, LaTeX, Vala, Haskell, OCaml, Java, Scala.
> 
> I'm currently only interested in building C++ and D, generalized
> tools that can manage multiple languages tend to be much more
> complex than I need.

To each his own, but I honestly don't see what's so difficult about
this:

	# src/SConscript
	Import('env')
	env.Program('mydprogram', ['main.d', 'abc.d', 'def.cc'])

	# lib1/SConscript
	Import('env')
	env.Library('mylib1', ['mod1.d', 'mod2.d'])

	# lib2/SConscript
	Import('env')
	env.Library('mylib2', ['mod2.d', 'mod3.d'])

	# SConstruct
	objdir = 'build'
	env = Environment()
	Export(env)
	env.SConscript('src/SConscript',  build_dir=objdir)
	env.SConscript('lib1/SConscript', build_dir=objdir)
	env.SConscript('lib2/SConscript', build_dir=objdir)

Main program in src/, two libraries in lib1, lib2, and everything builds
in build/ instead of the respective source trees. No problem. I even
threw in a C++ file for kicks.

Now granted, SCons does have its own flaws, but railing about how
useless it is when one hasn't even bothered to learn what it can do
sounds rather unfair to me.


T

-- 
Ruby is essentially Perl minus Wall.