Yeah, I would also be against making SCons our primary build system. I've also 
had some very painful experiences with doing anything beyond the very basics 
with SCons that have cost me many hours.

One of these experiences, in fact, was trying to get SCons to handle generated 
thrift files properly -- it was extraordinarily difficult, because the 
dependency system employed by SCons is entirely based upon filenames. If you 
don't know the names of files produced by a build step in advance (i.e. they 
are dynamic based upon the contents of a .thrift file), you end up having to do 
really weird things with temp files and what not to get it working.

Would also note that SCons has very limited/poor support for lots of the 
languages that Thrift employs, and as David mentions, extending SCons requires 
significant time and knowledge.

Conceptually SCons sounds very nice, it works very well for some projects and 
is far more elegant than autoconf/automake for the basics, but in my experience 
it tends to break down quickly when you find you need to push it a bit.

-----Original Message-----
From: David Reiss [mailto:[email protected]] 
Sent: Saturday, August 29, 2009 10:51 AM
To: [email protected]
Subject: Re: Building Thrift with SCons

I have had only negative experiences with SCons, mainly due to the fact
that it seems that you need to deeply understand the SCons internals
to do even trivial tasks beyond the basics.  However, if you want to
produce a SConscript for Thrift, we would be happy to include it in
contrib.

--David

Bruce Simpson wrote:
> Hi all,
> 
> We recently cut over to SCons, from GNU Autotools, in the XORP tree, 
> which is now public again:
>     http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/xorp/
> 
> So far this has been a win for us -- it is now much easier for us to 
> deploy new components in the tree, and maintenance is easier too, 
> assuming developers are Python-literate.
> 
> I wanted to ask if there is interest in SConsifying the Thrift tree, and 
> if anyone has already been working on this? It is likely I will need to 
> hack Thrift significantly to do the following:
>  * integrate Rush Manbert's excellent ASIO work;
>  * streamline the client/server stubs, and separate those which are 
> generated for C++;
>  * introduce support for fully async client-side invocation, with or 
> without futures (which XORP needs).
> 
> Please let me know -- I'd like to start work on this as soon as 
> possible, and would like to avoid duplicating existing effort.
> 
> thanks,
> BMS
> 
> 

Reply via email to