Sorry I didn't get this across well: I don't have an issue rebuilding normally (as you show below). The EDE issue was that if that first build that EDE forces you to do in the middle of its setup fails you're left without various config files being generated (like env_ede and the eclipse setup) and there's no easy way to just fix your issue and 'continue' -- ede forces not only a full rebuild of the sipxecs side of things but it also unconditionally rebuilds all of the dependencies. Once its made it through once and built all the config files everything's easy to work with.
Its nice to have a 'do everything in 1 step' EDE option, but it would also help a lot to have it just set up/check stuff rather than actually run the builds every time. Perhaps this is really only an issue when you're trying to build on an unsupported platform and will run into problems on the first build (as I was doing), I can see how the current stuff would be fine for anyone on FC10 where its known to work w/o error. -Eric On Apr 2, 2010, at 12:38 PM, M. Ranganathan wrote: > 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. > > > > > > -- > M. Ranganathan _______________________________________________ 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/
