[Scons-users] SCons popularity

Thu Jun 4 14:40:10 EDT 2015

Jason,

you've got provoked ;)

Anyway, my intent wasn't to start another holly war between SCons and
autostuff. It would be pointless. I'd just like to pointed out some facts.

Consider these two worlds: developers and package maintainers. If you
give an automake-based project to a Debian package maintainer, (s)he'll
just grab it and make a package, because there is a "standard interface"
found in most automake-based project that is used (without much effort)
by package maintainers. If you give the same person a SCons-based
project, he'll probably fail at first place or at least spend much time
digging through the project-specific documentation, because it's not
known a priori how to build and preinstall (certain parts of) this
particular project to appropriate place(s). Often, there is simply no
such way.

On the other hand, upstream developers who use SCons have to create an
amount of boilerplate to install their stuff in standard GNU locations
and provide necessary features (CLI flags, variables, etc) that enable
the project to be somehow useful for package maintainers. This has to be
repeated in every to project, because corresponding GNU standards are
not implemented anywhere in the SCons nor around it.

In short, what's is missing is a easy way to create GNU-friendly SCons
projects. I believe, this could be supported by some extension to SCons.

I guess, Debian currently has more than 30000 packages, and there must
be a lot of upstream developers irritated by the automake stuff who
would like to just switch to better build system. However, switching to
SCons may currently cost them losing interest of package maintainers,
because they read packaging guides :).

A "market" such as Debian's world should not be ignored. It may bring a
lot of upstream developers and package maintainers interested in keeping
SCons alive and supporting its development. The first step, however,
should be done by SCons. A measurable success would be seeing such texts
as I've cited previously to disappear or, better, to be replaced by
packaging guides for SCons-based projects :)

W dniu 04.06.2015 o 17:32, Kenny, Jason L pisze:
> Honestly I read this and it make it sound like autoconf is this perfect system. 
> 
> I have not seen these concerns myself about SCons, I don't know if other have. I wish these would be pushed as item to address vs the negative "oh don't use it" statement because I have an concern with it that I did not tell them about. 
> 
> I see stuff that I can never get to work with most autoconf build.  But to the points made about not adapting to the system setting I would say is a mixed bag. Commercially you would never do what is suggested here as you would never be able to ship a binary package that would work across distros. This is one of the main issues with unix vs windows. MS with all there faults made it easy to make a binary that works on all version of windows. This is not the case with linux, which has the view that the binary only needs to run on that system it was built on. However I don't see anything here that is a major issue to address. I would only state that it need to be controlled what to use. The main value I have with SCons with project I use it one vs autotools is clear and easy reproducibility. SCons duplicate the environment defined to it with the tools it is told to use so everyone gets the same bits. you don't have to worry about some random different in the shell to break the build. 

> 
> I have a addon to Scons called Parts that does address some of this. But honestly I never seen some of this and most autoconf project I have used don't seem to follow these rules as well.
> 
> Let me try to address some point as well. I will use Gentoo link as it seem better organized
> 
> --Ignorance of compilation environment settings
> This I believe is a misunderstood feature. By default SCons does not use the shell. This allow duplicate exact environments, which is much more effective ( and cheaper) than the make style copy exact machine setup. One main reason I seen SCons ( and at time with Parts) is because you can give that other developer the Sconstruct and they run it and it works. Never have this happen with autoconf. There is always something that is goes wrong, and then there is always something with the build bit that break from not being copy exact. 

This (ignorance of compilation environment settings) is a maintainers'
point of view, I think. They're not interested in SCons possibility to
use environment variables. They're interested in this feature being
actually present in projects they package. But upstream developers seem
to be too lazy to list in SConscripts all the shell variables they want
to copy to SCons environment, so they simply do not implement it. If
there was an easy way to copy a bunch of variables commonly used by GNU
tools, for example, they would be at better position to cooperate with
package maintainers.

> 
> I do sort of address some of this Parts. However there is more I can do. I am adding an --use-env switch to help use the shell ( I find this dangerous as it always cause the build bit to be broken on some system when used). However the reason I was adding this is that I have user in Parts that need to compile on some beta/alpha OS/architecture/compiler and the normal find the tools logic does not work, or there was some special hack to get the system working. Almost never do these system setup CC/CFLAGS etc in the shell correctly. However I see value in updating the toolchain/configuration fixes in have in Parts allow better support for this use model if it was selected ( vs doing it by default)
> 
> -- no default installation paths/commands
> First off make does not support make install as feature. It is a convention. SCons in the same way does not support scons install. I personally and many I work with find this a bad practice. Most project I have used don't support DESTDIR correctly as well and this again is just a convention. 

Yes it's a convention. But there is quite good support in automake to
implement this convention in projects. SCons does not provide this out
of the box, and I haven't seen extensions that would do.

> 
> In Part I do address this as well ( however I want to tweak it some more to make it better) by providing wrappers to scons Install() such as InstallBin(), InstallLIb(), etc.. so a build can easily be configured to control where stuff gets installed. By default Parts build code in a under a build directory and puts finial outputs into a install root sandbox. So the DESTDIR is used by default in Parts but I call INSTALL_ROOT.  There is more I could do to make this better. However SCons is a cross system built system, so it not bound to being targeted to linux only systems. That is why I and many other use it as it you can say build this hello.c as a program and it works on mac/linux/freebsd/Windows/android/ etc.. do that with autotools on windows using icl with the Microsoft 2013 compiler tool chains...
> 
> --No automation possible
> I don't agree with this. Targets like All, etc... are a convention. SCons unlike make provides a -c or --clean switch. You don't have this in make, so you might not be able to clean easily.  I agree that Configure ( if it is used and not emulated) takes a common set of inputs and this is a good thing. Scons does not define some of this stuff, main because it was not done yet or it not generally portable. Scons does however has a "all" target ( but not in the same way) you say scons .  the '.'
>  Mean build all target in the current directory and below.
> 
> In parts I do address some of these concerns in that I add many common options or value to control a build. Targets such as all in more of a make way in that it can be mapped to some set of targets. In Parts case it maps to the target build:: which is to say build allow "build" concept component targets vs other concepts like "utest". This allows breaking what is processed in a standard way. Likewise Parts add the notion of components ( called "parts") which allow the user a standard way to say build a given component and or any subcomponents etc... you don' have this level of control in Make without knowing the build rule to pass. SCons with Parts you have the ability to target any directory ( ie build everything under ./install or build a component with certain properties, etc.. Also Parts allow easy to control over easy rebuilding of the outputs for a different target and or configuration. This at best requires you to rerun autoconf to generate a new makefile in different direct
 o
r
>  y to switch to and the build. Scons and Parts all I need to do is:
> 
> Scons all   # build native platform ( by default)
> Scons all --target=x86  # build it again for x86
> Scons all --target=android-x86  # build it again with ndk for android-x86
> Scons all --target=android-arm  # build it again with ndk for android-arm ( I live in the USA so I don't have anything but arm options at the moment)
> ...
> 
> However like most build system you can add special unknown options that could break "automation" as if you did not know you have to add this, the build will not be good. SCons by default went for being flexible do whatever,. Parts tries to add some common conversion and structure. In that way SCons is like make, you can do all kind of stuff that is not expected. Unlike make SCons provides an API to allow you say what that is easily do people can do something with it.
> 
> --Constant reconfiguration
> Not really. Autoconf generate a make file with some options. One could make a autoScons program to hard code values in generate Sconstruct. However in generate SCons has an ability to be configured on the commonline. I use and tweaked a bit work in Parts to allow use of config files. There is an ability to have the SCons write out the config file for you is you set it up correctly ( don't use this in Parts... yet). As I stated above you have to reconfigure system like autoconf to cross build anything or us a different set of predefined option ( debug  release, etc..)  In SCons and Parts I can do a single pass cross build. Comments like SCons will not help you I would also disagree with. Yes there are need for better messages, but autoconf tells me nothing most of the time and fails and says everything is good. 
> 
> --No support for out-of-source builds
> Not really. This statement has a lot of details. SCons has a lot of support to build predefined packages. While SCons supports be default the ability to copy files to variant directory to allow certain "dump" tools to work correct. This does not have to be used. Scons makes it very easy to support multivariate build, reading sources from caches, etc. Many of these feature have to use better in Parts myself. So statements in this blob are just plain wrong in my view. There is more that can be done to make it easier to use predefined package I agree, but that I true with any build system. I don't see SCons being any harder than make in this regard.
> 
> 
> Hope this is helpful for you. I would recommend SCons myself. ( and Parts) I think the issue you have to look at is that SCons ( and parts) allow people to define one build script for many system, not one. This is cool and powerful, and yes there are items that can be done better. You other approach is to try to do a more generate a build script view for a given system and use that. That is what autoconf does on some system. People like myself work on new build system like Parts and SCons ( or WAF, Mavin, etc) because we wanted something better. 
> 
> Jason
> 
> 
> 
> 
> -----Original Message-----
> From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of Pawel Tomulik
> Sent: Thursday, June 4, 2015 7:02 AM
> To: SCons users mailing list
> Subject: [Scons-users] SCons popularity
> 
> 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?
> 
> --
> Pawel Tomulik
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> 

-- 
Pawel Tomulik