Hi Richard, I played around with this a while ago, and I managed to get it to work without handling environment variables. My build.sh had a not-very-elegant install_name_tool workaround.
cmake .. -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON -DCMAKE_INSTALL_PREFIX=~/miniconda3 -DPYTHON_INCLUDE_DIR=~/miniconda3/include/python3.4m -DCMAKE_LIBRARY_PATH=~/miniconda/lib make && make install install_name_tool -change libpython3.4m.dylib ~/miniconda3/lib/libpython3.4m.dylib ~/miniconda3/lib/python3.4/site-packages/_openbabel.so for l in xmlformat pubchem cmlreactformat cmlformat cdxmlformat; do install_name_tool -change libxml2.2.dylib ~/miniconda3/lib/libxml2.dylib ~/miniconda3/lib/openbabel/2.3.90/$l.so; done I have a version of this on their binstar site, but I don’t know if it works. I generalized the commands with conda's environment variables, but dropped the whole effort at some point. Hope this helps, Pat On Tue, May 26, 2015 at 1:40 PM, Richard West <r.h.w...@gmail.com> wrote: > In the thread below (was "Re: [OpenBabel-Devel] Google Summer of Code”) > there was some discussion of making conda binaries, for the anaconda > distribution. > > Pat wrote: > > Conda. The best user experience (if the binaries work), cross-OS, > language-agnostic, and a great virtual environment. I don’t think there’s > enough support to direct all users to conda, but it would be worth > supporting conda binaries, mentioning it in the getting started, and hoping > adoption grows. > > > For much the same reasons as his first sentence, we're trying to package > another tool (Reaction Mechanism Generator) for Conda. We’re almost there, > but one of the last dependencies is OpenBabel, so we're now making an > OpenBabel build recipe. I wrote the first Mac homebrew recipe for > OpenBabel many years ago, but haven’t really touched it since then, and am > far from comfortable with the build process. > > My current impasse is the need to set $BABEL_LIBDIR and $BABEL_DATADIR > https://github.com/conda/conda-recipes/issues/309 > > I expect when we get around to Windows build, we’ll need a lot more help. > > Is this mailing list a good place to seek help? Or github? Or elsewhere? > Don’t want to spam the wrong people! > > Is anyone already doing this? > > Thanks, > Richard > > -- > Richard H. West, Ph.D. r.w...@neu.edu > Assistant Professor, Department of Chemical Engineering, > Northeastern University, 360 Huntington Ave, Boston, MA 02115 > http://neu.edu/comocheng Phone: 617-373-5163 > > > On Feb 3, 2015, at 10:14 AM, Patrick Fuller <patrickful...@gmail.com> > wrote: > > Noel's python content is great, and I think a redesign would push > information like that to the forefront. > > I'm willing to migrate the website, which I can play with on a personal > github.io fork. I think you had some experience with avogadro and pandoc > - how did that turn out? > > Pat > > On Sun, Feb 1, 2015 at 11:43 AM, Geoffrey Hutchison < > geoff.hutchi...@gmail.com> wrote: > >> I certainly agree with a need for a better website. Noel's user >> documentation (https://open-babel.readthedocs.org/en/latest/) gives a >> lot about getting started and using Python. If you have suggestions, it's >> welcome. At the moment, I don't have the time to do a website redesign. >> >> As far as packaging, it's not really our job to intercede with >> OS-specific packages. Debian, Ubuntu, etc. have managers and a set policy >> about updates and what to install with the main package (i.e., not >> scripting bindings - that's a separate package). >> >> Now, you mention having a more frequent release schedule. That'd be >> great, but I'd really need people to step up to help as release managers. >> Given 2-3 people willing to help, we can certainly get a more concrete >> schedule - which I think would also help with your frustration at older >> binary packaging. >> >> So if people can provide a little help: >> - Website, possibly migrating to GitHub pages / Jekyll (i.e., re-using >> the Sphinx documentation) >> - Volunteering to serve as release managers >> >> -Geoff >> >> >> *From: *Patrick Fuller <patrickful...@gmail.com> >> >> ... >> >> In more detail: >> >> I think that the complicated install / getting started process is >> dissuading new users. This project would focus on the new user experience, >> particularly the first 30 minutes after someone decides to try open babel. >> The goal should be to get novice programmers properly set up and writing an >> interesting script (an a-ha moment) in this time.This would lead to a >> couple of sub-projects: >> >> - Information organization. There is a ton of information in the open >> babel website, but the home page is daunting for new users. As a good >> example to follow, I’d point to django’s website >> <https://www.djangoproject.com/> - there’s a big “Get Started” button >> right when the page loads. This is an intentional choice, and described by >> the django founder in this talk >> <http://pyvideo.org/video/403/pycon-2011--writing-great-documentation> >> . >> - Scripting as a first-class citizen. I think a tutorial should >> cover basic tasks through the command line, C++, and python. The >> information is already on the website, but it just needs to be >> presented to >> new users quicker. >> - Installation. A large portion of scientific coders aren’t >> particularly good at software (see software carpentry >> <http://software-carpentry.org/>), and don’t have the ability / >> desire to debug things like cmake output. There are packages out there, >> but >> they’re tied to an old version of open babel and don’t install everything. >> Hard drive space is cheap- open babel should install everything through >> every installation method with build options to disable. Approaches: >> - OS-specific package managers, e.g. brew, apt-get, yum. >> Maintaining all of these separately is a hassle, but I’ve been told >> good >> things about effing package management >> <https://github.com/jordansissel/fpm> as a translator. Other >> challenges include: can’t use most recent commit (I think homebrew is >> an >> exception), and doesn’t play well with virtual environments out of the >> box. >> - Language-specific package managers, e.g. pip. It’s a hassle to >> compile through these package managers, but they play well with >> language-specific virtual environments and git (e.g. pip install >> git+https://github.com/openbabel/openbabel). >> - Conda. The best user experience (if the binaries work), >> cross-OS, language-agnostic, and a great virtual environment. I don’t >> think >> there’s enough support to direct all users to conda, but it would be >> worth >> supporting conda binaries, mentioning it in the getting started, and >> hoping >> adoption grows. >> - Versioning. New releases every x months, and ideally a simple >> workflow to propagate a new version to all supported package managers. >> >> If I can help further, let me know. >> >> Pat >> >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> OpenBabel-Devel mailing list >> OpenBabel-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openbabel-devel >> >> > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. > http://goparallel.sourceforge.net/_______________________________________________ > OpenBabel-Devel mailing list > OpenBabel-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbabel-devel > > >
------------------------------------------------------------------------------
_______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
