These are chat archives for symengine/symengine

23rd
Aug 2015
Ondřej Čertík
@certik
Aug 23 2015 00:00
@isuruf the Ruby wrappers as well as the Python wrappers should ultimately go into a separate directory. Both will require the libsymengine.a (or .so) library to be present and installed (that library should still be installed using cmake, as it is). Then we should use the native Ruby (gem) or Python (pip) way to install the wrappers.
From the Ruby or Python perspective, the C++ library is already installed and you can assume it is "given". Then the job of the wrappers is to just link against it and call it from Ruby or Python.
Isuru Fernando
@isuruf
Aug 23 2015 04:53

@certik, what do you mean by

Then we should use the native Ruby (gem) or Python (pip) way to install the wrappers

Isuru Fernando
@isuruf
Aug 23 2015 06:16

With CMake, I can come up with a solution like this,
find_package will look for symengine with all the correct configurations. i.e. with all the optional dependencies correct (we can add compilerId and other things too)
If not found, then ExternalProject_Add will compile libsymengine

In ruby and python, we just call CMake underneath.

If we are not using CMake, we'll need to come up with something that is equivalent to SymEngineConfig.cmake and SymEngineConfigVersion.cmake

Ondřej Čertík
@certik
Aug 23 2015 15:42
@isuruf for Python at least, I was thinking of just using the distutils. That way the wrappers become just like any other Python wrappers, e.g. h5py, but I just looked at it (https://github.com/h5py/h5py/blob/master/setup_build.py) and it looks really hackish.
So I think we should just stick with calling cmake underneath.
Isuru Fernando
@isuruf
Aug 23 2015 15:45
Okay, one more thing, what should be done if SymEngine is not found, build it in the python wrappers CMake project or ask that they be installed?
Ondřej Čertík
@certik
Aug 23 2015 15:46
Definitely ask that they are installed.
That way developers are not surprised by any potential unwanted download/installation.
Most people will be using symengine through Conda, Hashdist or Sage, or Debian/Gentoo/...
So we want it to be easy for the package maintainers to maintain.
Isuru Fernando
@isuruf
Aug 23 2015 15:49
So the only option that the user can give when installing is the symengine_dir and it would searched before system paths
Ondřej Čertík
@certik
Aug 23 2015 15:50
It searches for the cmake configs installed by symengine?
Isuru Fernando
@isuruf
Aug 23 2015 15:50
Yes, or it could be a build directory
Ondřej Čertík
@certik
Aug 23 2015 15:53
The use case that we need to mainly optimize for is installing symengine somewhere (either /usr like in Debian, or just some kind of installation directory like in Conda or Hashdist) and then be able to point the Python/Ruby wrappers to it.
So I think your current solution would work.
Isuru Fernando
@isuruf
Aug 23 2015 16:02
How can the python wrappers know where to find the symengine library, when it is Hashdist?
Isuru Fernando
@isuruf
Aug 23 2015 16:10
sys.prefix would work right?
Ondřej Čertík
@certik
Aug 23 2015 16:23
Hashdist just installs symengine into some directory. Then hashdist points the Python wrappers to it, e.g. by depending on symengine (the C++ lib) the $SYMENGINE_DIR will point to where it is installed. So the we just pass this path to the Python wrappers to find the cmake config there.
Isuru Fernando
@isuruf
Aug 23 2015 16:27
Alright, also are we disabling installing directly by cmake? If so, then we could just pass the python library, python include_dirs from the python script, instead of the FindPython.cmake script
Francesco Biscani
@bluescarni
Aug 23 2015 16:49
@certik here's a post about what I have been doing in Piranha in the last month or so, thought you might be interested: http://bluescarni.github.io/new-series-multipliers-in-piranha.html