This is a proposal for implementing SCons Windows Installer improvements, standalone executable, and VHDL builders.

• Nathan Brown
  1-319-573-5548 [CDT -0500]
  Yahoo! IM : shiften
  nathan AT sputnickonline DOT com

SCons is a cross-platform software build tool, performing much the same functions as autoconf+make on Linx or Ant for Java. The benefit of SCons is that it's simple to start using and can be configured handle many different toolchains.

One of SCons' goal is to get the user productive as quick as possible regardless of the platform they install it on. On Microsoft Windows platforms, additional work is needed to get a user going as quickly as possible. It would be preferable to integrate SCons into the environment as natively as possible so users know what behavior to expect.

To further this goal of working better on Windows, two major tasks are going to be taken on by this proposal. The first of these is to build a new Windows installer. This would package SCons and any pre-requisites it has for running along with the hooks into Windows so that it will behave and look like a normal application and be ready to go with only one install. The second task is to make Python install and work on environments without Python pre-installed. This could involve making SCons work as a standalone executable or through bundling Python with the installer or having the installer download it if missing from the environment.

An area of personal interest is embedded platforms, and that includes FPGA development. Having a VHDL Bulder would push into that area in a big way and provide a much needed tool in that area. This is another task taken on by this proposal.

For the general scope of this project, The Windows Installation and Standalone Executable sections following are extracted from the SCons website, while the VHDL Builders section is personal. This project will address each of these to provide future users of SCons the additional functionality and ease of use.

The current SCons self-extracting Windows installer is generated by the Python distutils package. This approach limits SCons to existing as a Python module and not as a real, first class build utility. As a build utility, SCons would show up in the start menu, be able to install several side-by side versions, and be uninstalled like any good Windows application.

There are still sites that don't have Python installed. And sometimes an application can only be run with a particular version of Python. Adding packaging logic so SCons can be shipped as a self-contained unit would help lower the barrier to entry for those sites.

To enable very high performance computing, FPGAs are being relied on to provide a high degree of parallelism. One programming language which targets these devices is VHDL, many of the tools are still command line driven and would be greatly served by support from SCons in parsing the dependencies during a compilation, and speeding recompilations. This would be for both Windows and Linux versions of the tools.

The benefits to the user community of each of the enhancements described above would be less time installing the SCons utility and configuring it to perform the tasks required, and more time coding. My primary computers are loaded with Windows Vista and Windows XP. I have access to Linux, but find that my productivity in that environment does not increase and I miss access to some of my preferred applications. I want to support tools and applications which have chosen to be cross platform compatible and perhaps contribute to enhancing them on Windows.

Obviously, I am interested in using SCons for my VHDL projects as currently I use either vendor supplied GUIs or batch files which simple compile every file each time they are run. These tools all run on both Windows XP and Linux and I see that SCons could provide a valuable benefit to both platforms even without builders. It will only be that much easier when native support is available and someone can start using it right away without manually inputting every file they have in their project (which can get large in a hurry).

A Windows Installation should provide everything that a user would need to get started using SCons. This would include the following functionality:

• Install SCons as a standalone utility
• Multiple versions of SCons on a single system (side-by-side)
• SCons access through the Windows Start Menu
• SCons access through Windows Explorer through double-clicking or a right-click menu on SConstruct files.
• Ability to uninstall through the Add or Remove Programs control panel
• A Windows help file or other windows compatible manual for reference. A trade study would be performed to acquire available options to implement this and then a recommendation would be made for each choice. This initial study would then be the guide for the actual implementation of the windows installer portion of this project.

A standalone executable should provide a way to deliver the SCons utility being installed as a way to run without any pre-requisites not normally found on a standard Windows installation. The install should also avoid breaking existing applications which depend on specific versions of Python. Several option exist for this:

• Compile an EXE which contains SCons
• Package Python along with the Installer
• "Bootstrap" or automatically download Python if it is missing on the system. A trade study would be performed to evaluate the options and performance of those options. One of those would then be implemented to go forward for SCons by this project.

My interest in SCons is because I am interested in FPGAs and their VHDL programming language. A good cross-platform make replacement is needed and I would like this opportunity to implement just that in SCons. This would involve:

• VHDL Builder
• VHDL Scanner
• A Tools Module for Mentor Graphics ModelSim
• A Tools Module for Altera Quartus
• A Tools Module for Xilinx ISE These would be implemented and tested and submitted to the SCons website.

The Windows Installer and standalone executable shall be compatible with Windows 2000, XP/Server 2003, and Vista/Server 2008.

The installer shall be compatible on each of these platforms in 32bit and 64bit mode if available.

If the SCons executable is implemented only in 32bit, it shall be able to call target commands that are both 32 bit and 64 bit.

The VHDL builders shall be compatible with both Windows and Linux industry standard tools. These tools are Mentor Graphics ModelSim, Altera Quartus, and Xilinx ISE. Each have 64bit and 32bit executables for both Windows and Linux.

This project will use standard best practice methods in each of the areas of development. Software engineering methods will be used to design, develop, review, and test the code for this project.

Several tools to bring these new functionalities to SCons have been suggested by project organizers. These include WiX, a Windows Installer file builder and py2exe or PyInstaller, both Python script packagers. These tools or similar will be evaluated and selected for inclusion in future SCons development if they provide the functionality required.

Also, general development tools will be used. I will use Microsoft Visual Studio 2008 for building the right-click context menu handler for SCons and for building the help files. An Icon editor will be found and used to develop or modify an icon for the start menu.

http://msdn2.microsoft.com/en-us/library/bb530410.aspx - Windows Vista Application Development Requirements for User Account Control Compatibility

http://msdn2.microsoft.com/en-us/library/aa286552.aspx - Windows Application Compatibility Toolkit 3.0

http://msdn2.microsoft.com/en-us/library/aa372866.aspx - Windows Installer

http://www.installsite.org/ - InstallSite: Resources for Setup Developers

http://www.vhdl.org/

Currently in SCons, there has been some interest in wrapping up the tool into an installer. On suggestion has been WiX, a toolset which builds Windows installation packages using XML files. There is a contributed WiX scanner for SCons to support building an installer package. Other open source applications such as Tortoise SVN also use WiX. Personally, I have only used NSIS (Nullsoft Scriptable Install System), this does not produce an .MSI Windows Installer file, but instead an executable.

Looking at how Python does it, they have custom DLLs and python scripts which help make and install the application from an .MSI installer. Perhaps they did this because they didn’t have access to tools like WiX or perhaps they do this to handle the complexity of various windows platforms and hardware architectures (9x/2000/XP/Vista and x86/x64).

There seems to be a trend towards the .MSI Windows Installer files and away from standalone .EXE files. Microsoft has been promoting MSI and they also have tools that help a system admin push out these installs to a whole domain of computers.

I think that .MSI Windows Installer file would be the preferred way to provide a packaged release of SCons for Windows in the future. What I would be doing is compiling a list of available tools, find some tradeoffs, try one or two, and then in the paper for the white study report show this process and what the plan going forward would be.

There are several options here, the major categories are this; package into a standalone executable, or include (or bootstrap) the Python Installer.

The obvious advantage to the standalone executable category is the smaller size since Python’s supporting files, such as all the supporting documentation and additional modules is not included. This would also isolate SCons from any version changes the user decides to make to the main installed copy of Python. With the upcoming 3.0 release of Python, this may be a benefit.

The resulting packaged SCons would be expected to pass all the regression tests and if those need adjusted to fully test the new delivery format, then those tests would be added.

On the other hand, SCons is not meant to be isolated from any modifications the user may want to make to it or the supporting python script files it uses. If the supporting builder files are not exposed, how is a user going to enhance them or learn from them to make better ones? So perhaps we have two user groups here, the developer who is building and involved in the build tool for their project, and those that just write code for the project and expect the build environment to “just work”.

The other major category was to include the Python Installer in its entirety, or to include code to check for its existence, and if it is not found, ask the user if they would like to download it from the web. The full install of Python 2.5.2 is 10.8 MB. Including it would make the current install of SCons increase in size by almost 19 X. Also, many downloads are updates, and those users would not need a bundled copy of Python. So this leaves bootstrapping, or auto-downloading Python from the internet if required. This could also check for the most recent version of Python and let the user update if they so desire. An argument against this would be those computers not connected to the internet when SCons is installed, and the inclusion of SCons on hard media such as a CD. In those cases, the user would have to be informed that Python needs to be installed separately.

During the beginning of this effort, work would be done to try out these different approaches, document what was discovered, and then select a viable approach.

This is really a small side thing to the effort that would benefit the largest number of the development community. I would test SCons for building VHDL projects both for simulation and FPGA layout and through this. The tools supporting VHDL would be tested on a project, mostly by doing it the GUI or batch file way, and then the command line options that they use to make the calls would be put into the SCons VHDL builders. Then I would design some language specific builders to parse the VHDL and determine dependencies.

At the end of the performance period, the following items will be the deliverables. The method of delivery is also included. The delivery methods include e-mailing the SCons developers mailing list, checking code into subversion, and adding content to the SCons wiki.

Progress Reports

• [D-1] Weekly updates e-mailed to mentor

• [D-2] Mid-term progress report e-mailed to mentor and dev mailing list.

• [D-3] Mid-term evaluation submitted to Google.

• [D-4] Draft of final progress report e-mailed to mentor and dev mailing list

• [D-5] Final progress report e-mailed to mentor and dev mailing list

• [D-6] Final Evaluation and report submitted to Google. Trade Studies

• [D-7] Windows Installer trade study and selection.

• [D-8] Standalone Executable method trade study and selection Code Patches of SCons submitted to dev mailing list and then checked into repository when approved. These include both functionality and test harnesses to check generation and correct functionality when installed.

• [D-9] Generator scripts for Windows-style help

• [D-10] Additional needed content for Windows-style help

• [D-11] Windows Installer script

• [D-12] Windows Shell right-click handler

• [D-13] Standalone executable generator scripts if trade study recommends this option Updated documentation on the SCons wiki

• [D-14] Notes on use of Windows Installer

• [D-15] Notes on ability of right-clicking on SConstruct files

• [D-16] Notes on using SCons installed as an application. Also, the VHDL Builders.

• [D-17] Add VHDL builders information to SCons wiki. The required end of project Code Submission.

• [D-18] End of project Code Submission to Google through their website form.

[[!table header="no" class="mointable" data=""" Task | End Date | Produces

1. Learn Python through tutorial | May 5 |
2. Prepare weekly status reports | Weekly | [D-1]
3. Generation of Windows-style help | |
   a. Design a generator script | |
   b. Work on tests | |
   c. Work on generator script | |
   d. Test generator script | |
   e. Prepare patch | May 12 | [D-9]
4. Work with Mentor Mid-term progress report | July 11 | [D-2]
5. Mid-term evaluation and progress report | July 14 | [D-3]
6. Additional content for Windows-style help | |
   a. Work on additional content | |
   b. Review additional content | |
   c. Prepare patch | May 13 | [D-10]
7. Standalone Executable | |
   a. Work on method trade study | June 6 | [D-8] b. Review method trade study | |
   c. Design generation script | |
   d. Work on generation script | |
   e. Test packaged executable | |
   f. Prepare check-in for Standalone Executable | June 16 | [D-13]
8. Windows Installer | |
   a. Work on trade study | |
   b. Review trade study | June 23 | [D-7] c. Design installer creation | |
   d. Work on test of installer package creation | |
   e. Work on test of installer operation | |
   f. Work on installer scripts | |
   g. Test Installer generation | |
   h. Test Installer operation | |
   i. Prepare check-in for Windows Installer | July 21 | [D-11] j. Update Installer Documentation | July 28 | [D-14] k. Design right-click handler | |
   l. Implement right-click handler | |
   m. Prepare check-in for right-click handler | August 4 | [D-12] n. Update right-click documentation | August 11 | [D-16]
9. Work on VHDL Builders | August 18 | [D-17]
10. Work with Mentor on Final Report | August 25 | [D-4]
11. Prepare Final Evaluation | September 1 | [D-5], [D-6]
12. Code Samples to Google | September 3 | [D-18] """]]

I don't have an Apple computer and will thus be unable to deliver a .dmg file. Some of my friends have Apple laptops and I may give this a try if I can borrow one. This would be a stretch goal.

I have been exposed to Python and I've looked through the SCons source code, but I haven't programmed in Python as of yet. I expect it to take no more than 2 days to catch up. I have significant mastery of a variety of other programming languages and don't expect this to be a problem (assembly, C++ (inc. MFC), C#, java, ASP VB, VHDL, etc.).

I’ll be on vacation with my wife from May 15th through June 3rd.

I also have some other work for this summer, but am expecting to be able to devote at least 25-30 hours a week to SCons work and will be able to complete my project if awarded.

I have submitted no other proposals in Google Summer of Code.

Nathan Brown

http://www.sputnickonline.com/

I have an engineering degree from LeTourneau University and have chosen to continue my education in graduate school to gain an MBA degree at University of Iowa. My passion has been programming and circuit design especially for low level hardware such as microcontrollers and FPGAs. I have also completed several GUI programs for my hobbies or school projects.