Tuesday, July 18, 2006

 

SCons Builder for EiffelStudio 5.6

SCons is an alternative to make. It's cross-platform and, because it's scripted in a general-purpose programming language (Python), it's extremely flexible.

I've written a SCons tool to automate EiffelStudio 5.6 builds. It probably also works with 5.5, 5.4, etc., but I've only tested it with 5.6 on Windows and on Mac OS X 10.4.7.

It definitely won't work with EiffelStudio 5.7, which replaces the venerable .ace file with the shiny new .ecf file. I'll also have to update my SCons tool when I upgrade to 5.7.

If you're frustrated with make files, give SCons a go.

Comments:
Frustrated with make, how so?

And what if you want to take your scons build to a new machine? I suppose you have to install a raft of new files as well.

Using SCons, unless there are some extremely valid reasons to do it, will mean less people will compile and use it, because while everyone has make no one has scons.
 
A big problem with using make for Eiffel builds is that make isn't portable. Unix and Microsoft variants have irritating inconsistencies, and then if you want your Makefile to do things such as 'rm' a file you either have to run it under Cygwin on Windows or else live with maintaining two sets of Makefiles.

With SCons, it's easy to write portable scripts. My Eiffel SCons script, for example, works on Windows and Mac, and probably on most Unixes and Linuxes.

The book "Practical Development Environments" by Matthew Doar, published last year, has a table on page 86 comparing various build tools (make, Ant, Jam, SCons, etc.). SCons rates strongly on all criteria; make is weak on all points except its strong user community. My experience matches this.

The only prerequisites for using a SCons script are:

1. Install Python (which many machines already have).

2. Install SCons.

Those two steps take a few minutes.

If make works for you, then great. For us, make was causing headaches. I considered using geant, but then I heard good things about SCons.
 
I am a scons fan too... I have some half made Scons modules to use on Eiffel that I should publish at some time.
 
What I usually tend to find is that people have no idea what you can do with Makefiles. So I'm missing 99% of the functionality that make gives me, have to write much more code, and the build process runs much slower because all those tools are nowhere near as smart as make.

And with make you have the full power of the unix command-line at your fingertips. If you have to delete the occasional file I suppose doing that in any scripting language is ok. But often you need to do a lot more.

But anyway, two people who like scons, I certainly will have a look.
 
Every time you add an extra dependency, you reduce the number of people who will successfully install your application.

SCons is great, but it needs a working Python installation. I think it's more common to find a working 'make', or the ability to easily install a working 'make'.

As Berend says, 'make' is very powerful. But there's a problem: much of the functionality that makes Gnu 'make' so fantastic is not present in proprietary 'make's.

The Parrot developers have been through this same dilemma. They decided that Python doesn't run on every weird platform that they might want to compile Parrot on, so they had to reject SCons.

They found also that proprietary 'make's such as AT&T 'make' were missing some of the functionality that made Gnu 'make' such a good solution. This led to two options: require that Gnu 'make' is installed, or use the cruddy subset that is supported by all versions of 'make'.

They settled for the latter option, because a working, viable installation is always better than a powerful elegant one that won't work because of some missing dependency.

Of course there's another option: write the installation program in Eiffel and distribute it as an ANSI C package. That's a core part of the SmartEiffel installatino process, and it sure helps to make it easy to install on a wide range of platforms.
 
Roger wrote, "SCons is great, but it needs a working Python installation."

I can imagine people being deterred by the need to install Python, but I think that's easily overcome by giving them a direct link and pointing out that it's easy and takes only a couple of minutes.

Installing Python and SCons is quick and painless. Working around the deficiencies is make: now that's a real time waster.
 
Peter, I guess the difference is that everyone needs to have Python installed, whereas only the developer needs to "work around the [alleged] deficiencies of make".

Not that Python is such a bad thing to have installed, of course.

Now that SmartEiffel has a framework for embedding scripting languages, and Perl as a sample implementation, I'd love to see a corresponding Python embedding.
 
Roger, I don't understand what you mean when you say, "everyone needs to have Python installed, whereas only the developer needs to 'work around the [alleged] deficiencies of make'."

The only people who need Python installed in order to build a system with SCons are developers. End-users don't need to build the system, so they don't need SCons. Any developers wanting to join a project will need SCons, and yes, they'll need to install Python; but the alternative is for them to use make and so confront make's problems. They are developers.

Is there some intermediate party who is not a developer but still wants to build the system? I suppose some projects might involve such people; e.g., if I want to build some project from source, then it would be a minor hurdle to install SCons and Python; but if I'm going to the trouble of building it rather than installing binaries then I'm already going to a whole lot more effort anyway.

So, Roger, I don't really see your point.
 
Peter, I can't really install any binary on my system. They usually fail to missing or incompatible binaries.

So I build almost all of the software I use.

Also note that on FreeBSD systems most people build the software because they use portinstall.

When Eiffel software becomes more complex it might also have more dependencies. So many that a typical end-user cannot really install it without compiling it.

The only way around it is static linking. Which causes some other problems.

I think that is what Roger was pointing at, that distributing binaries isn't always a viable option.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?