-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of M. Ranganathan Sent: Friday, April 02, 2010 10:38 AM To: Eric Varsanyi Cc: sipX developers Subject: Re: [sipX-dev] Sustainable open source -- suggestions solicited.
On Fri, Apr 2, 2010 at 12:18 PM, Eric Varsanyi <[email protected]> wrote: > >> Questions I have for the developer community : >> >> 1. Development environment : EDE has helped a great deal in lowering >> the barrier for participation. Kudos to Paul for that. Is this enough. > > EDE is great to bootstrap to a working setup. My biggest issue with it is the multi-hour wait between each 'cycle' when there's a problem and its non iterative nature. I've hacked the build script (violently) to keep it from rebuilding all the dependencies after a simple compile error almost every time I've used it (5 or 6 times). > > I had to build something like this for new developers on our commercial product. A pattern that seems to work well with completely virgin (to a codebase) developers and is still useful to veterans is a helper tool that knows all the subtle dependencies needed to make a build work and then make a running development environment (just like EDE). It helps set up the environment (creating a file with env vars needed, creating dirs, etc) but then also reports on dependency or other environmental issues rather than just starting from scratch each time. Each aspect of the setup should be runnable individually (ie: "build me an eclipse config, everything else is fine", or "remake the env-ede file", or "check that I have all the needed deps to run a build and tell me what's broken") as well as in a single 'do it all' step. This tool ends up being rather useful in the build section of an RPM as well. > > I still don't understand the difference between a 'designer' build and a normal checkout/make build other than the designer build pushes to a local install tree and normal build pushes to /usr/local (and a 'normal' build doesn't run for me since December). > > Making incremental changes and testing them is very painful, it should be possible to 'make' and run from the same tree w/o installing and a normal' make' should only really build the one .o that changed (for C/C++ projects) and relink. Likewise for Java stuff you should be able to make/ant/mvn, get the jar or other artifacts generated then just restart the daemon w/o a lengthy install/deployment step. You can go to the particular build directory and from there run configure ( your cwd has to be in that directory) then make all install for example, from BUILD/sipXbridge rm Makefile ../../sipXbridge/configure make all install You do not need to make all install every time from the root of the build tree. You can also run autoreconf in the particular src directory you want to reconfigure. for example cd sipXbridge autoreconf -if Make sure you delete the old Makefile.in I agree I had to find out by experimentation (this should not be necessary). I'll update wiki. Many in the user community, or implementation community might be more accurate, are simply not programmers, unless you count writing in quick basic or early visual basic as being acceptable. That is not to say I for one don't have an interest in development. I believe a post last week that talked about building some funding options for development of features might be a great solution. As an example, if a pot was out there to develop a feature for a few thousand bucks, there may be developers that would be interested in doing the work. I'd propose one pot for now - a pot to pay a developer to create the documentation and the processes to overcome the shortcomings that keep developers from getting involved. Maybe that is paying some of the people who have left the team recently to sit down and create a detailed document to assist new developers. Baby steps are always good, and might be a great way to start reshaping the project as a whole. Simply looking at the number of emails on the dev list demonstrates that things are changing........................ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
