[Scons-users] SCons popularity

[Paweł Tomulik]

W dniu 12.06.2015 o 11:56, Dirk Bächle pisze:
> Hi Paweł,
> 
> thanks a lot for your question(s), sorry that I can address them only
> now...but I was away for some (holiday) time. ;)
> 
> On 04.06.2015 14:02, Paweł Tomulik wrote:
>> Hi,
>>
>> I am using SCons for a few years for and for a few reasons:
>>
>> - it's extensible (Tools) and flexible,
>> - build scripts expressed in a civilized and powerful language,
>> - dependencies handled correctly even in parallel builds and without
>> additional developer's effort,
>> - it's free and open source :)
>>
>> Generally it has a powerful core and it would deserve for a great
>> interest, but it's missing few crucial features that make it rather
>> unpopular. It looks like open source developers and package maintainers
>> are being instructed to strive away from using SCons, see for example:
>>
>> - https://wiki.debian.org/UpstreamGuide (section called "SCons"),
>> -
>> https://wiki.gentoo.org/wiki/SCons#Why_you_should_NOT_use_SCons_in_your_project.
>>
>>
>> My question is: are the SCons developers going to address these issues?
>> I've seen efforts regarding versioned shared libraries, hope it's going
>> well. There are no easy ways (an no plans?), however, to support
>> "standard" installation targets. So, any plans to make it better with
>> this regard?
>>
> 
> You are basically right, there is no visible and concentrated effort
> planned at the moment to make this all "better". I can only speak for
> myself here, because I *do* have a very clear vision of which steps
> should be involved to let SCons stand out from the crowd...or be at par,
> at least.
> 
> The current switching of the core sources to using "slots" is a part of
> this, as well as the special "subprocess" wrapper that we'll integrate
> next. Combined with destroying the rumours about SCons being slow
> (http://www.scons.org/wiki/WhySConsIsNotSlow , yes I know the wiki
> doesn't work :) ) this should give some leverage to gain more avid users.
> Other current steps in this direction are:
> 
> - Released "fastcpp" Tool for speedup of large, flat CPP builds.
> https://bitbucket.org/dirkbaechle/scons_fastcpp
> - Started a CMake to SCons converter (such that one can better compare
> real-life projects, regarding runtimes).
> https://bitbucket.org/dirkbaechle/cmake2scons
> - Started a special "autotools" wrapper Tools, supporting things like
> DESTDIR and BINDIR for example. (Not available yet)
> 

Some time ago I've started similar project:
https://github.com/ptomulik/scons-gnu-build/. It implements most of the
autotools' variables (bindir, and friends) in the sense that they may be
passed from command-line (and/or shell environment) to scons
environment. It also provides a flexible framework for defining custom
variables "shared" between user/os and scons environment. There are also
few other things such as standard autoconf tests implemented and some
extra checks (e.g. recognizing available compilers, compiler versions,
checking for compiler/linker flags availabililty). The missing part is
the installer  functionality (I think of specialized installers for
binaries, python libs, man pages, shared libraries etc.). If you're
interested, we could join efforts somehow?

> Especially for the last item, I'm trying to wrap one of my own
> open-source projects into SCons...but "automake" style, including
> installing and packaging.
> If anyone is interested in this kind of work, please put your finger
> up...and chime in. Because there's only so much that a single man (me,
> and the other core devs) can do. ;)

Of course, I am interested.

> 
> Best regards,
> 
> Dirk
> 
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users


-- 
Paweł Tomulik, tel. (22) 234 7925
Instytut Techniki Lotniczej i Mechaniki Stosowanej
Politechnika Warszawska