On Saturday, 27 October 2012 at 18:11:30 UTC, Russel Winder wrote:
Or it says you know Make but not SCons. All build frameworks
have their
computational models, idiosyncrasies , and points of pain. Make
and
SCons both have these.
I definitely do not like Make. The scripts are made out of
garbage, and maintaining garbage just produces more waste.
Unfortunately for me, my attempts to make use of scons is not
encouraging. It may be better than Make, but not enough for me to
settle down with it.
The problem most people have when moving from Make to SCons is
that they
think Make computational models and idioms. It takes a while to
get over
these and appreciate that SCons is very different from Make
even though
it is fundamentally the same.
The two problems I mentioned were encountered almost immediately.
These are inability to scan subfolders recursively, and inability
to build to a level above the source folder. I don't think that
neither requirement has anything to do with thinking in terms of
Make. It could be that solving these two deficiencies may be
enough to keep me going with scons, I don't know.
Hummm... Whilst I am a fan of "out of source tree builds" I
have always
build within the project tree, so I have never noticed that
trying to
build in a directory that can only be reached from .. of the
SConstruct
appears to be impossible – without use of symbolic links.
Will you put
in the bug report or should I?
I don't think it's a bug, because it's actually documented as a
feature. It may however be a "bug" in terms of the assumptions
about how applications should be built.
Does Make? CMake, Autotools, Waf?
I have only used Make, and as bad as it is, at least I can scan
subfolders with one built-in command.
Yes and no. Clearly there is a core of idiomatic things that
every build
framework should have. Then there is stuff that is unique.
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.
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.
At this point I'm considering looking at those old build tools
written in D, perhaps I can patch one of them up to get it to
do what I want.
Or fix SCons?
I thought of that, however in order to fix scons, I would have to
learn a lot about scons, and also learn Python. The flaws that I
see with scons are so basic, I probably would not fit in with the
scons culture, so I see nothing but pain in trying to fix scons.
I'm also learning D, and would rather spend more of my time
learning D than something else. My only interest with scons is
for using it, not fixing it, and I have no interest in learning
Python.
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.
(*) Think SCons → Python → Monty Python.
That's how I view most of what is going on in programming land.
--rt
