[Asterisk-Dev] Dev call 1.2 release discussion

Travis taxtell at CLEMSON.EDU
Sun May 8 13:58:13 MST 2005


I think that developers should look into, and consider scons, a python
based make system, as an alternative.   http://www.scons.org

"Building asterisk should not depend on having python"
Scons is designed to run from python 1.5.2, something from the era of
RedHat 7.  I find it near certain that any person compiling asterisk has
a system with python 1.5.2 or greater.

I have spent considerable time trying to understand the autotools.  I
have not found them to be generous.  Despite their age, they remain
poorly documented and cryptic.  Maybe it is just me, but M4 macros seem
old and prove to be a challenge to effectively use easily.

I have very little experience with python.  I'm an electrical engineer
and I only act like I can code.  I have set up Scons to compile
gnophone.  I found it an easy AND ENJOYABLE process.

If you are looking for more advanced projects using Scons, you do not
have to search far.  Blender, Ardour, Battlefield 1942, etc were all
built using this system.  The website has a listing of large projects.

I know that brc_ on IRC has spent time working on making asterisk using
Scons, perhaps he can chirp in on this, too.

Before you shoot it down, look into it.  I feel that you shall find it
an admirable choice of an alternative to gnu make that is modern and
simple, though powerful.

I also find the 'make menuconfig' idea to be interesting.

Thanks,
Travis A.


Matt Fredrickson wrote:

>On Fri, May 06, 2005 at 01:40:41PM -0700, Luigi Rizzo wrote:
>  
>
>>On Fri, May 06, 2005 at 03:31:51PM -0500, Brian West wrote:
>>    
>>
>>>Autoconf and pals have been offered up twice totally working and they  
>>>were going to help maintain it.. but in the usual fashion Digium and  
>>>gang ran that guy off.
>>>      
>>>
>>the point is not having the working when they come, or for a while,
>>but to be sure that there is widespread knowledge on how to maintain
>>them so when the guru in charge disappears someone else can take over.
>>
>>To this, there is nothing like good documentation and easy and
>>stable tools.
>>    
>>
>
>Yeah, the trick is not in getting a single person that will maintain it, but
>in that whatever build system that is used has to be acceptable enough to a majority
>of the developers that actually contribute code that they are willing to
>use it.  I'm not certain that there are enough core developers familiar
>with auto* tools right now (or want to become familiar enough with them) to
>attempt some sort of migration to them.
>
>My personal view on the matter is that the autotools are not a very good
>answer.  We were considering this at one time in the past so I ended up
>buying a book to learn the various GNU Auto* tools.  In the course of
>reading it, I came to the conclusion that they seemed to be more work than
>they were worth, so I abandoned the prospect.  I am interested in
>seeing Jeremy's "menuconfig" to see if that is a more palatable solution.
>
>Matthew Fredrickson
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>  
>




More information about the asterisk-dev mailing list