Closed sanjayankur31 closed 9 years ago
Sweet! Give me some time to look into this and then get back to you.
I've created a Fedora repository here and tested the packages too. They work really well :)
https://copr.fedoraproject.org/coprs/ankursinha/auryn/
$ mpic++ sim_isp_orig.cpp -lboost_program_options -lauryn -lboost_serialization -L/usr/lib64/mpich/lib/ -lboost_mpi
Seems to work fine for ubuntu installs too. Since there exists no without-mpi version, wouldn't it be good to have -enable-mpi switched on per default? I will try building against OpenMPI now and MPICH2. I like the solution, but might keep it in a branch until further notice, until I am completely accustomed to it. Will also require some rewriting of the docs for which I do not have much time right now.
Sure. Enabling mpi by default is probably the better thing to do.
Some of the code may need minute changes too. For example, autotools defines VERSION, so it doesn't have to be declared in the code explicitly.
Alright, let's keep the autotools version running in parallel for a while as a branch and see how we proceed. Since I am very much used to the current work flow (and have tight control on the compile parameters) I would like to have both in parallel anyways. One for simulator development and one for deployment for people who are rather interested in using the simulator. Also, as you said compiling from the static library works like a breeze. What I still have not fully understood is why binaries compiled using the static library are substantially smaller than binaries compiled directly from the object files. I find that strange ...
F
On 12/03/2014 10:46 AM, Ankur Sinha wrote:
Sure. Enabling mpi by default is probably the better thing to do.
Some of the code may need minute changes too. For example, autotools defines VERSION, so it doesn't have to be declared in the code explicitly.
— Reply to this email directly or view it on GitHub https://github.com/fzenke/auryn/pull/6#issuecomment-65380497.
Hrm, not really sure about the size issue. I'll have to look into exactly how it works. I found this on a quick google search:
http://stackoverflow.com/questions/12013800/why-is-my-binary-much-smaller-than-my-object-file
The autotools branch should probably be easily rebasable over master - it doesn't touch sourcefiles at all, only the build files. I can keep this up to date, since this is the version I've moved my work to now.
The autotools branch should probably be easily rebasable over master - it doesn't touch sourcefiles at all, only the build files. I can keep this up to date, since this is the version I've moved my work to now.
Okay let's keep it like this for now. I added your branch locally as a remote and I will keep it up to date to play with it. This way we can decided later if we maintain it separate or if it will become master at some point.
Works on my Fedora 21 system with mpich2. Hopefully it'll work on everyone's systems. I tested sim_isp_orig with and without mpiexec and it worked just fine.
I haven't tested make install yet, but I suspect it should work just fine. Currently, we generate both static and dynamic libraries.