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".

Reply via email to