On Thu, Dec 2, 2010 at 9:06 AM, Michal Bielicki <[email protected]> wrote: > Am 01.12.2010 um 07:59 schrieb Douglas Hubler: >> I pulled a "thread" so to speak when adding all the dependencies for >> openacd and related support and refactored release engineering scripts >> a bit. >> >> Highlights >> * Use mock utility now instead of installing rpms after building. >> Cannot say how amazing this tool is (thank you Russ H.!), almost as >> amazing as it is slow the first time you warm the yum cache. mock is >> also invaluable to testing rpm specs and dependencies before >> production installation. Unfortunately rpm builds are order of >> magnitude slower, but the benefits are worth it. > > Could that be selectable ? What if I do not want to use mock ?
yes, in fact you have to run --enable-rpm to even see the targets. The src.rpms can be built w/o mock and may be your best way to feed into another autobuilder system. If you're dead-set against using mock or if mock is available on your rpm-based distro (suse?), it's possible we can write alternative to mock targets that feed these src rpms to the old style of building and installing locally w/sudo and hide that nastiness in a single make file that is not enabled unless explicitly done so. >> * lib/* projects got moved to ./* because location can be subjective >> in the grand scheme of things (e.g. ./lib/sipx-openfire and >> sipXopenfire). It also make things easier for release scripts > > And kills the idea of separating out all the dependencies into ONE git > submodule instead of multiples pulling in freeswitch and openacd as a single and direct git submodule made sense which precludes this decision to use one repo. we wouldn't want a submodule in an submodule because as it stand, openacd already has submodules so it would have been sipx -> submodule:lib -> submodule:openacd -> submodule:mochiweb plus, i really like the fact that freeswitch is on the same level as say sipXproxy. When FS was hiding in ./libs it gave the impression it's off hands and that cannot be the case anymore. Same goes with openacd and openfire. They are all equal members of the big sipX family now ;) >> * all rpm build logic was removed from individual projects. This >> should make supporting non-rpm distros cleaner > > nice, but how do we build rpms now ? i need to document this, but essentially # step 1, install mock and make a tweak to the mock config. Also setup a tiny local web-server, (explain more in doc) ./configure --enable-rpm make sipx.rpm or for deps make lib.rpm >> * larger binaries were removed from git and uploaded to >> download.sipfoundry.org. Download of tars is seamless and can be >> avoided by pre-downloading files. > > is there a make download command ? What does one do on a closed system to > predownload ? i can provide rsync access to http://download.sipfoundry.org/pub/sipXecs/libs for anyone that needs it, by default you send it to ~/libsrc. Or you can run recursive wget if you're looking for quick fix. Issue is that the URL the deps is now canonical and if there is a minor change inside the tar, the name needs to change. this should be the case anyway >> * freeswitch spec, is very, very close to freeswitch's spec including >> building of all modules. I'll try to position my minor changes to FS >> upstream so all files can be identical. > run a sed on build ? i don't know what you mean here. i already have FS in a fork on github so i can track changes for sipx fairly easily, so it's not about using sed to apply a change. My point about being identical is so that someone can drop in freeswitch built from anywhere and be rest assured it will work. We might maintain a few bug fixes working there way upstream, but compatibility wise, it should be identical. >> * reduction of lines of code in release engineering scripts from 12K >> to 3K and there is even more that can be dropped i haven't got around >> to yet. The 3K includes new functionality like iso creation and >> sipfoundry publishing and 6 or so new deps/projects. Over the years >> the copy/pasting boilerplate code got out of hand. > > :) big ;) >> * scripts much easier to maintain and add to >> * ability to add new sipX project or dependency building with almost >> effort by adding just one entry to top-level script. >> * helpful targets like: >> >> make sipXivr.all-install... >> which starts at project sipXivr and continues thru the list to the >> last sipX project. This is useful when some target fails at a project >> and you wish to pickup where you left off. The ellipsis will work for >> most targets (e.g. sipXivr.rpm...) including lib targets. type "make >> sipx.list" or "make lib.list" to see order. >> >> make list-missing-deps >> which analyzes your distro and build requirements of all sipX spec >> files and prints packages you're missing in a format that can be feed >> to yum > > could they be also fed to the build system so it builds all the deps you are > missing that are in tree ? that's the magic of mock, now list-missing-deps is only useful for developers looking to build and install from source. Specific example, erlang shows up as a missing deps however if you are looking to build rpms on your local machine, you never even have to install erlang?! It gets pulled into your chroot without you even knowing or caring. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
