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 >
