[Scons-dev] Re Install information update[was Re: SCons doesn't bootstrap without libxml2]

[anatoly techtonik]

On Wed, Feb 19, 2014 at 11:42 AM, Russel Winder <russel at winder.org.uk> wrote:

> On Tue, 2014-02-18 at 23:19 +0300, anatoly techtonik wrote:

> […]

>> My opinion is that by adding additional dependencies to run the SCons

>> without errors from a fresh checkout we are significantly increasing

>> contribution

>> barrier and discouraging people from participating.

>

> I agree that this might put off people interested in helping to develop

> SCons. However this has nothing to do with people taking up SCons for

> production builds.


People taking up SCons for production builds of what? SCons itself or
production builds of their own products? The latter auditory is not affected.


>> People need to checkout and run to see the power of SCons. Not read,

>> checkout, install, setup, run cycle. Something like this.

>

> Again for potential contributors to the project yes, but not for take up

> and traction.

>

> The SCons install page talks about Fedora first, Debian second (and who

> uses apt-get when aptitude is available?) and Windows as a footnote,

> 32bit Windows at that.

>

> This page clearly needs to emphasize 64-bit in this day and age, Windows

> and OSX since they are the hard ones. Ubuntu, Mint, RHEL, CentOS all

> need to get into the role call.


SCons clearly needs people to reduce talks into commits. =)
Integrating Parts ASAP and enable cross-platform builds.


> We should also be thinking about Scons in Eclipse (i.e. advertise

> SConsolidator and get equivalents for IntelliJ IDEA, NetBeans, etc.

> Perhaps most importantly, most commercial C and C++ development happens

> in Visual Studio, so why aren't we plugging SCons in the MSBuild space?


Because it is hard to integrate. That's why.


> A few more observations whilst I am at it: D, Go, the whole JVM-verse

> have their own build frameworks and do not use SCons and are less and

> less likely to each day. Indeed Gradle is now getting traction as the C

> ++ build tool to replace Make for those doing C++ with some Java or vice

> versa.


People entertain. It is their right to use the tools that they can expand.
The only goal that SCons has is that it is written in Python, but when
people see that they can not expand it, they switch to a more popular
alternative.


> So if we are talking about support for development, CI please, for pull

> requests.

>

> SCons is my "go to" tool for LaTeX, C and C++, but sadly most people end

> up using CMake. Poor them.


I am not using SCons at all for my projects. They all web and Python,
but I need to get access to SCons core to reuse it for other graph building
tasks, such as deploying a network infrastructure.