IMHO what you need is a python script who is independent from the OS which it will cope your dependencies as maven does for building all the stuff.
2011/8/10 dsh <daniel.hais...@googlemail.com>: > Hi Jean-Sebastien, > > thanks for your feedback. You are right as long as Tuscany native > hasn't been released as a pre-build package that can be installed on > an operating system it doesn't make sense to use libraries as > dependencies coming pre-packaged with a particular OS or package > management system. Instead I should setup my own staging area > containing all the various dependencies. Tho, in the long run I am > interested in pushing those dependencies as FreeBSD ports into the > FreeBSD ports tree cause there you could have development snapshots of > a certain library as a FreeBSD port which would allow to use the > dependencies coming with the FreeBSD ports tree instead of manually > compiled ones (we did that with DSPAM development snapshots in the > past). > > on another subject - Is there a new Tuscany native release planned > anytime soon? M3 seems to date back to 2007. I am asking cause at > least at the time you would plan to ship a new release -- and maybe > even pre-build packages for certain Linux/Unix distributions such as > DEBs or RPMs -- you would have to use the packages available on a > certain OS. > > Cheers > Daniel > > On Wed, Aug 10, 2011 at 5:26 AM, Jean-Sebastien Delfino > <jsdelf...@apache.org> wrote: >> On Tue, Aug 9, 2011 at 3:53 PM, dsh <daniel.hais...@googlemail.com> wrote: >>> Hi Jean-Sebastien Delfino, >>> >>> some things I noticed during the configure process (I am using MacPorts): >>> >>> * I think it would help to point out in the INSTALL file that mozjs >>> can be downloaded at -> ftp://ftp.mozilla.org/pub/mozilla.org/js/ >>> * On OSX Lion xulrunner won't install from MacPorts and thus one would >>> end up without a proper mozjs installation >>> * If compiling mozjs from the prio mentioned URL, it ends up to be >>> installed as /opt/local/lib/libmozjs185.1.0.0.dylib which causes the >>> configure process to fail >>> * I thus symlinked /opt/local/lib/libmozjs185.1.0.0.dylib to >>> /opt/local/lib/libmozjs.dylib >> >> I usually run configure >> --with-js-include=$build/tracemonkey-bin/include/js >> --with-js-lib=$build/tracemonkey-bin/lib >> with $build pointing to a non-system directory; >> >> ... after having built trace monkey like this: >> curl -OL http://hg.mozilla.org/tracemonkey/archive/e4364736e170.tar.gz >> mv e4364736e170.tar.gz tracemonkey-e4364736e170.tar.gz >> tar xzf tracemonkey-e4364736e170.tar.gz >> cd tracemonkey-e4364736e170/js/src >> $build/autoconf-2.13-bin/bin/autoconf >> ./configure --prefix=$build/tracemonkey-bin >> make >> make install >> >> ... and on Mac OS X this additional step: >> install_name_tool -id $build/tracemonkey-bin/lib/libmozjs.dylib >> $build/tracemonkey-bin/lib/libmozjs.dylib >> >> I've never had much luck installing libmozjs in the system directories >> for all kinds of reasons. On Ubuntu and Redhat I had conflicts with >> already installed incompatible versions, dependencies dragged by >> xulrunner, and IIRC similar issues on Mac OS X with macports too. >> >> Thanks for the link to js 185, I'll try it on Ubuntu, Redhat and Mac >> OS X too, happy to switch to it if it works on these systems, but I'd >> like to avoid installing it in the default system directories (hoping >> there's a way to specify the install dir with --prefix). >> >> More generally I try to stay away from using pre-built packaged system >> dependencies for the following reasons: >> >> - most of the times they system dependencies conflict with the >> versions of the dependencies I want, for example Ubuntu 10.10 ships >> with Apache httpd 2.2.16 which is really old compared to the 2.3.10 >> version used by Tuscany; >> >> - using the system dependencies shipped with the operating system >> means versions on different systems, different behavior and >> significant effort to port and test with all these different versions; >> >> - if I need to debug or patch them I'll have to recompile them anyway, >> and if I do that then I'll have to install them in a non-system >> directory to not mess up my system; After all, that's the beauty of >> open-source, you can get the source, compile it yourself and install >> it wherever is most convenient for you... >> >> - if I need to install Tuscany and its dependencies on a new machine >> (an EC2 VM for example), it's much easier to build and install all the >> dependencies in the same directory as Tuscany, zip that directory up, >> and transfer that zip to the target VMs without altering its system >> directories. >> >>> * The configure process is looking for -lapr-2 instead of -lapr-1 (I >>> have APR 1.4.5_1 installed) >>> * I thus had to symlink /opt/local/lib/libapr-1.0.dylib to >>> /opt/local/lib/libapr-2.dylib >> >> Yes I've been using apr-2 as it's required by httpd's mod-session for >> crypto. See the related email discussion on the httpd dev list there: >> http://markmail.org/thread/dbavlf55ywf2a33h >> >> I don't think that APR 1.4.5 includes the crypto API required by httpd >> 2.3.x mod_session_crypto yet, so we're stuck with APR trunk for now, >> until APR releases that API and httpd ports to that release. >> >>> >>> If you like I could try to update the INSTALL document accordingly and >>> attach the patch to a JIRA. >> >> That would help, but what would help even more , I think, would be to >> have a script that downloads / checks out the dependencies and builds >> them end to end on a particular system. The single INSTALL doc may get >> really big if we start to add to it all the different instructions to >> build off system dependencies on Ubuntu, Redhat, Mac OS X, FreeBSD >> etc... >> >> There's already a script to build everything on Ubuntu 10.x there: >> https://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/ubuntu/ubuntu-install >> >> There's another one for Mac OS X Leopard and Lion there: >> https://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/macos/macos-install >> >> ... which by the way should help you build on MacOS without fighting >> with any system dependencies. With that script, you should be able to >> build on a pristine Mac OS system + GCC 4.4+ from Macport or other, >> without polluting your system directories with any other dependencies >> at all... as all required dependencies are built from source by the >> script. >> >>> I am doing the dependency setup in >>> parallel on FreeBSD 8.2 to see whether I would run into similar issues >>> (for instance the one of having a -lapr-1 installed instead of the >>> expected -lapr-2). We could then decide whether we want to improve the >>> auto* tools infrastructure or not (or even migrate to CMake). >>> >>> PS: I am planning to create a FreeBSD port for Apache Tuscany (native) >>> cause I feel having to setup all of these dependencies is kind of >>> daunting. >> >> Cool, it'd be really cool to have another similar build script for >> FreeBSD too :) >> >>> Cheers >>> Daniel >>> >> >> -- >> Jean-Sebastien >> > -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. "Favola -Moda".