Make [was Re: SCons and gdc]

[Rob T]

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