On Sat, Jul 13, 2013 at 5:53 PM, Russel Winder <[email protected]> wrote:
> On Tue, 2013-07-09 at 09:17 +0200, Dirk Bächle wrote: > […] > > In my view, bootstrap.py is more for creating the build packages. It can > > also copy together a local working copy (the "bootstrap" folder), which > > is fine for most cases when you simply want to start SCons without fully > > installing it. > […] > > I think we perhaps need to clarify the role of bootstrap.py then as I > have always known it as the entry into using the current HEAD as SCons > >From my research it looks like historically the bootstrap.py is used to "compile" SCons from HEAD. This includes building documentation, fixing headers and versions strings, as well as gathering files required for packaging. As a side effect, the environment prepared by bootstrap.py was suitable to run SCons in standalone mode. The bootstrap.py also plucks at SConstruct to test that HEAD still works correctly, so it is a good practice to run that file periodically. Since https://bitbucket.org/scons/scons/commits/a917420bcc2c5d35730d02b32ec29af25d345c0f it is possible to run SCons directly from source code. This is not ideal though, because version imported may be different from the source code if there is SCons installed into Python's site-packages. I think we should change this, so that the version called will always be the correct one. Using boostrap.py leads to > having all the pyc files not in the checked out repository which is a > Good Thing™. Trying to use a shell script instead leads to pyc files > being in the checked out source tree, not good at all. > Good Thing™ is a bad argument. I don't care about .pyc files - they are ignored anyway. Ability to run SCons without building anything is a Good Thing™. Which one is better? =)
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
