[Scons-users] Debian/Gentoo SCons 'recommendation'

[Evan Driscoll]

On 01/11/2016 04:27 PM, William Blevins wrote:
> It's complicated, but the main argument is that expect to interact 
> with packages in an GNU Autotools specific sort of way; this is also 
> why they discourage Waf while praising Make (but with emphasis on 
> using autotools paradigms.

I can give a perspective on that as someone who for a while was building 
from source a lot of misc software. (Background: when I was in grad 
school, there was a student-maintained network drive volunteers could 
install software to. So if you wanted some weird piece of software, or a 
newer version of what was available, you could put it there and make it 
available to anyone interested.) Because we were putting things in 
non-standard locations, we often needed to pass extra flags to tell it 
where to find certain dependency libraries, sometimes a newer compiler 
version, and always an installation directory.

Now, I don't actually recall hitting any SCons-using projects I didn't 
write, but what I can tell you is that the easiest things to build were 
almost always (1) autotools projects and (2) cmake projects. If it did 
something else (e.g. straight make), it usually took a little more effort.

And for me the reason isn't tools interacting with the build in an 
"autotools-specific sort of way," it's/me/. If you give me an autotools 
project that is in C or C++, I know right off the bat:

* I can pass CC=foo CXX=bar to get a different compiler
* I can almost certainly pass PKG_CONFIG_FILE=/whatever to let it find a 
library in a non-standard location
* I can pass --prefix=/inst/dir to tell it where to install

I'm sure it's possible to break each of these, but the point is (from my 
understanding, never having had the misfortune of actually needing to 
work with autotools) you have to go out of your way to make them /not/ work.

When building an autotools-based package, I almost never had to look at 
any kind of build instructions, aside from seeing the list of 
dependencies so I could install and point pkg-config at them. It just 
worked.

CMake on the other hand I never internalized how to do stuff on the 
command line, but it makes up for it with ccmake and cmake-gui, which 
give you a nice interactive way of specifying where to find libraries, 
installation directories, etc.


Contrast with SCons. Yes, you /can/ provide those variables and options 
to make it behave the same way, but SCons doesn't give you any 
particular support to do it. There's no encouragement to, say, use 
"--package=/inst/dir" as opposed to "PACKAGE=/inst/dir". In fact, SCons 
actively goes out of its way to /discourage/ this kind of configuration, 
with the ignoring env-vars thing. (That has a ton of plusses too of 
course, but I'd prefer if 'scons CC=/whatever' worked out of the box, 
for example. That's an explicit request to use a specific complier.)

If I ran across an SCons project that I wanted to install, I wouldn't be 
able to just /do/ it like I could with autotools and CMake projects; I'd 
have to go figure out how to build /that specific project/ first, and 
that knowledge wouldn't carry over to the next SCons project.


Now, don't take this as me knocking SCons too much. SCons in some ways 
is trying to solve a more difficult problem than autotools is -- 
autotools has no interest in running with non-Unixy systems for example, 
and is primarily aimed at a Linux, open-source demographic. SCons feels 
equally at home on Windows, using Windows build tools, which autotools 
can't say. (Though CMake can, mostly.) But I still think that fact that 
SCons doesn't provide /out-of-the-box/ functionality for doing the 
things I said above is a marked deficiency. It's still in contention for 
best build tool in my mind, but in spite of that problem rather than 
because of it.

Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160111/9d718a24/attachment-0001.html>