Create Continuous Integration Builds

[iwillspeak]

The travis continuous integration build at https://travis-ci.org/rust-onig/rust-onig is currently failing. There seems to be an error preventing the dynamic linker from finding the libonig that we build for the onig_sys crate.

• - Build on OS X
• - Build on Linux
• - Build on Windows

[iwillspeak]

It turns out the OS X build want failing locally as I had oniguruma installed by homebrew too.

[iwillspeak]

Ok. So the build works on OS X because the linkpath is stored in the libraries. Linux can't run the tests because ld.so can't find the oniguruma library because it's not in the search path and Rust doesn't use rpaths. I'm going to create a separate branch for getting the build working on linux and looking into Windows build support too.

[iwillspeak]

As of 1e362be the Travis build works on both OS X and Linux. Time to setup a windows build.

[defuz]

Are you sure that storing .so and .dylib files in the repository and build the project by using them is a good idea? Users may need to linking our crate with specific onigurama build (it provides a lot of flexibility during assembly, see regint.h file).

I think we should write a guide to building a package on various OS and use this scenarios in travis-ci, but we do not have to provide only one possible way to build the library. In other words, we need to remove build.rs and instead offer the user build the project on their own. For example, I used a homebrew to get onig.so on OS X.

Btw, why we use dylib for OS X?

[iwillspeak]

Are you sure that storing .so and .dylib files in the repository and build the project by using them is a good idea? Users may need to linking our crate with specific onigurama build (it provides a lot of flexibility during assembly, see regint.h file).

We don't store sos or dylibs in the repo. We store a copy of the latest source. The build.rs file will try to search for an installed Oniguruma version first using pkg-config, if none is found then it will unpack the source and build that.

I think we should write a guide to building a package on various OS and use this scenarios in
travis-ci, but we do not have to provide only one possible way to build the library. In other words, we need to remove build.rs and instead offer the user build the project on their own. For example, I used a homebrew to get onig.so on OS X.

If people want to use a different version of Oniguruma with our code they just need to build it and install it as they normally would. The build.rs will then find it via pkg-config and emit the required flags to get rustc to link against their install. I'm quite happy with this for now.

This process is similar to that found in other rust ffi bindings. The only real difference from say the libgit or llvm bindings is that we use a tar rather than a git submodule to contain the third party source code. This is mainly because there isn't a definitive repo with the onig source in it. There is however a repo with the onigmod source in it which is why i've opened an issue to discuss switching to that fork of the codebase instead. It seems to be a bit more maintained than the original oniguruma source we have in our codebase.

Btw, why we use dylib for OS X?

Dylib is just OS X's name for dynamic link libraries. It's pretty much the same as a Linux so file or a Windows dll.

[defuz]

If people want to use a different version of Oniguruma with our code they just need to build it and install it as they normally would.

Ok, I got it. This is a good decision. Perhaps we should describe this in the documentation.

This is mainly because there isn't a definitive repo with the onig source in it.

I thought that https://github.com/kkos/oniguruma is the main repository of oniguruma, isn't it? Homebrew download library from there:

https://github.com/Homebrew/homebrew/blob/master/Library/Formula/oniguruma.rb

May be we can use the same approach: just download it during building process

[iwillspeak]

Ok. I'm going to take a look at the Windows build side of things over the next few days. I'll have a look at switching to that repo as part of those changes. When I have done that I will update the read me to add build instructions too.

[defuz]

It seems that https://ci.appveyor.com supports Windows containers for CI. At least regex crate use them:

https://github.com/rust-lang-nursery/regex/blob/master/appveyor.yml

[iwillspeak]

Yes. I was planning on using Appveyor for the Windows builds. I just
haven't had the time to create a powershell script to perform the build
yet. I was thinking it might be easier to switch to the GitHub repo for the
onig source first as that supports CMake. We can then just use the Rust
CMake build.rs crate instead. What do you think?

On Sun, 31 Jan 2016 at 04:37, Ivan Ivaschenko notifications@github.com
wrote:

It seems that https://ci.appveyor.com supports Windows containers to CI.
At least regex crate use them:

https://github.com/rust-lang-nursery/regex/blob/master/appveyor.yml

—
Reply to this email directly or view it on GitHub
#6 (comment).