[Scons-users] SCons popularity

[Kenny, Jason L]

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. 

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. 

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 directory 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