[Scons-users] SCons popularity

[Russel Winder]

On Sun, 2015-06-14 at 03:10 -0400, Ray Sheppard wrote:
> Hello again William,
>    I am giving you my impressions of the product. I already said I am 
> 
> not a developer.  I will address some of your comments.  Today's 
> supercomputers seldom permit serial code.  All code is parallelized. 
> Usage of 10's of thousands of ranks is not uncommon.  The general 
> build 
> directory is a working scratch file system.  Installations must put 
> their executables in a different file system.  Several systems do not 
> 
> even have home directory access during the execution of a job.  While 
> 
> computer scientists seem to love shared libraries, in a modern 
> system, 

I am not sure "computer scientists" really care. The whole shared
library thing comes from a period in history when disc space and main
memory were scarce. Running multiple executables with copies of all the
same code was seen as a violation of "do not repeat yourself" (DRY) and
so the shared library system was created. Saves disc space and memory
space at the expense of severe dependency management problems.

There is a move now, exemplified in Go, to always do static
compilation. Having 60MB or 100MB executables is seen as small penalty
for the lack of dependency management.

> they needlessly light up the network fabric in order to slow down 
> execution.  Often, shared expectations (as in *.so) must be 
> accomplished 
> as a a static import from a *.a library. This creates complicated 
> compiling systems.  Using a Cray as an example, the underlying 
> compiler 

For MPI-based, cluster-based systems, it makes a great deal of sense to
statically compile all the executables, especially for SPMD style
parallelism.

> might be gcc/gfortran.  However, the actual compiler has a name like 
> ftn.  It has a section for putting ftn specific flags (first section 
> of 
> the compile line) as well as native compiler flags (middle section of 
> 
> the compile line). Code which is looking for a clue, like mpicc to 
> decide if it is an MPI code is out of luck because the compilers 
> parse 
> the code and auto link in its version of message passing as well as 
> most 
> common math libraries without specific links. Adding in unnecessary 
> links (like -lmpi) only result in an aborted compilation. All of this 
> 
> requires modifications (from my experience) deep in the SCons 
> specific 
> files.  When I use the term "head" I am referring to the framework's 
> ability to divine its surroundings and make decisions. Your framework 
> 
> certainly does try to do that. I have read and even hard copied 
> printed 
> your user guide. Were I creating a project and trying to use SCons to 
> 
> write it, your user guide would be very helpful. If I have a package 
> that thinks it has write permissions to /usr/local and needs to have 
> specific flag structures, it is not so much.  I do not wish to write 
> my 
> own builder or scanner.  I just want to invoke a build with something 
> like:
> scons all INSTALL_ROOT=/somewhere CC=something CFLAGS= "-x -y -z" 
> FC=something_else FFLAGS="-a -b -c"
> Reading variables like LD_LIBRARY_PATH and CFLAGS rather than making 
> up 
> a new ones like LIBPATH  (or at least aliasing one to another) would 
> be 
> a nice touch.  I seem to have missed that section of the UG. Again, 
> this 
> is just the impression of someone who uses your product.  You can do 
> with these comments as you wish.

I haven't done any hard core parallel programming on real
supercomputers using C++ for 20 years, but with my tinkering using C++
with MPI, OpenMP, OpenCL, etc. on stock Linux and OSX platforms, I have
never found I had to delve into the internals of SCons to get things
working. I have had to experiment a lot due to lack of tutorial and
manual material, and to find idiomatic and Pythonic ways of expressing
things in SConscript and SConstruct files, but generally all the
variations have been handled at the Python level and not at the "get
inside SCons" level.

For a really trivial example:  
https://github.com/russel/Pi_Quadrature/tree/master/C%2B%2B

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150615/fdefdabe/attachment.pgp>