The uploaded nightly builds for Linux do not include the OCaml bindings. Do we know if the bindings will be added in the future?
Is building from source the only way to get OCaml support? From a previous question (Compiling z3 ocaml binding in linux) it seemed that the building system was not ready yet for Linux. Has that changed?
We will soon have a new OCaml API for Z3, and binaries will be included in the nightly builds.
The current OCaml API in the official release is old and does not support new features available in Z3. The new OCaml API will have the same capabilities of the .NET, Java and Python APIs.
The ml-ng branch is the working branch for this new API.
Related
Goal
I am using Bazel to build a multiplatform C++ client (iOS, OSX, Android, Windows).
iOS and OSX are built locally on my Mac (out of necessity). Android and Windows are built inside a Docker container.
At the end of the build I have a Bazel rule that takes each cc_binary rule for each platform and puts them in a .zip.
I'd like to utilize Bazel's remote execution API to build some of my binaries in the container and others locally and then reference a shared cache to collate them together -- all with one bazel build command.
Bazel support
Bazel claims that these types of multiplatform builds -- where the host (OSX x64), execution (Linux x64), and target platforms (many) are all different -- are possible.
See https://docs.bazel.build/versions/master/platforms.html
My experience
However, I hit this exact issue: https://github.com/bazelbuild/bazel/issues/5397 (where docker-sandbox is a correct proxy for remote builds.)
This, alongside the below Github issue, makes me question Bazel's claim about multiplatform builds.
https://github.com/bazelbuild/bazel/issues/5309
Fundamentally, these issues seem to say that local targets for one platform (e.g., OSX) cannot be built alongside remote targets on another platform (e.g. Linux).
Question
I was wondering:
(1) Is what I am trying to do fundamentally at odds with Bazel's design? If so, what is meant by Bazel being multiplatform?
(2) Is there a workaround I can employ that maintains hermiticity and stays within the Bazel build system? It could be possible to mount a Docker volume and then write a script that combines the Docker cache with my local cache, but it seems like Bazel was built to handle my use case. Am I missing something here?
Related questions: Does bazel support remote execution on different platforms? (Doesn't have a satisfactory answer.)
(1) Is what I am trying to do fundamentally at odds with Bazel's design?
In theory no, in practice yes. Bazel provides functionality which allows users to support your use-case, but it is not implemented by default.
Specifically, as described in the linked Bazel issues: Bazel rules currently make assumptions about the relationship between the host and target platforms which don't hold in your case, e.g. it will auto-detect the JDK files on your host (macOS) and then default to using these JDK files across all Java actions - regardless of target platform.
If so, what is meant by Bazel being multiplatform?
In practice, it means that you can run bazel build ... on multiple platforms and expect that Bazel will transform your inputs into outputs compatible for the current platform.
(2) Is there a workaround I can employ that maintains hermiticity and stays within the Bazel build system?
Yes, you can run bazel build ... from within a Windows VM or Docker container. This was the workaround that the Bazel team recommended when I asked this question.
Relevant advanced Bazel features:
If you want to build for multiple target platforms with one Bazel invocation, have a look at Bazel user-defined transitions (this would allow you to build the same rule for multiple platforms, e.g. iOS and macOS at once, but require you to write your own rules).
If you don't want to run bazel build from within containers/VMs, you can write your own C++ toolchain. At its core, Bazel gives each action a sandbox with all dependent files and guarantees that it will execute a specific command. In a custom C++ toolchain, you could tell Bazel to call a script instead of clang, which takes the command + the files and executes them from within a VM or container. This is likely a lot of work, but is definitely possible.
Currently travis supports linux (ubuntu?) and mac.
I'm currently exploring nix. I think it's a powerful way to declare the global state of your system. It's available at various level:
nix: package
nixos: machine
nixops: deployment
With the current state, I could install nix the package manager on a linux vm and get all the packages I need, great!
In my ideal world, I could do the same at the machine or at the deployment level (machine[s]).
So my question is: When will travis-ci will support NixOS? When will travis-ci will support multiple machine setup (let's say with NixOps) ?
it would be nice to be able to share /nix/store between travis builds. but for nixpkgs we're already try to build changes using nox tool.
https://github.com/NixOS/nixpkgs/blob/master/.travis.yml
I'm new to makefiles and jenkins.Is there any guide on how to write makefile to run build and the unit test together using jenkins.?
You can definitely use Makefiles to build and run both your application/library and tests.
Here is a good guide to Makefiles:
http://mrbook.org/tutorials/make/
It should help you with writing a simple makefile. For more information, Google is your friend.
Another good guide is here:
http://www.cs.swarthmore.edu/~newhall/unixhelp/howto_makefiles.html
Remember, jenkins and makefiles are completely unrelated. You can use Jenkins with makefiles, and use makefiles without jenkins. One is a continuous integration system, the other just another way of building your software.
You can go ahead and use Xserver as suggested in the other post, but Jenkins has advantages that many other systems don't: it is extensible using a whole host of plugins, has a large user and developer community and is used for multiple types and styles of projects in various languages. While your project is purely for iOS, there are other things in Jenkins you could take advantage of from the available plugins list.
There is an XCode plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin
Maybe this helps too:
http://programming.oreilly.com/2013/04/upward-mobility-automating-ios-builds-with-jenkins.html
But maybe you are better off using Xserver if you try to do continuos integration:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/xcode_guide-continuous_integration/200-Adopting_a_Continuous_Integration_Workflow/adopt_continuous_integration.html
I am working with a team that develops a Java application using the following well-established toolchain for automated building, testing and continuous integration:
OS: Ubuntu
IDE: Eclipse
Build tools: Ant
Testing framework: JUnit
Source control: Subversion
CI server: Jenkins
A typical Jenkins job will grab the Java source from Subversion, and run Ant targets to build the code, run automated tests and create deployment artifacts.
We are now considering writing a .Net plugin for Windows clients to access our application's API from MS Excel. We will probably write it using either C# or F# - it's early days, and we haven't settled on a language yet, but F# seems as if it may offer some benefits in terms of being able to express API actions using a combinator-based DSL.
We would like to do as much of this work as possible on Linux, using Mono, and to use our existing CI infrastructure to build and test our software.
My first impression is that the toolchain will look something like this:
OS: Linux
IDE: Monodevelop / VIM (Eclipse support for Mono, and especially for F#, seems lacking)
Build Tool: NAnt
Testing framework: NUnit
Source control: Subversion
CI server: Jenkins, with NAnt plugin
Does anyone have any experience of developing with this kind of toolchain? The two questions I would like answered are:
What are the main pitfalls in this approach for developers used to the Java ecosystem?
Are there better alternatives to NAnt and NUnit for building and running automated tests, especially for F#?
Using F# with MonoDevelop on Linux seems like the way to go if you're developing cross-platform or server-side applications that can be developed on Linux (and occasionaly tested on Mac/Win).
However, I don't think that you'll be able to develop Excel plugin on Linux if you're targeting Windows users. You'll definitely need to run Excel on Windows and to test things, you'll probably also need to do (a part of) the development on Windows (I suppose the integration is the tricky bit - though you could develop & test some core functionality on Linux).
On Windows you can use free Visual Studio Shell with F#. The MonoDevelop integration for F# is (hopefuly) quite good, but Visual Studio gives you probably better experience and you'll need to use Windows for quite a few tasks anyway...
What are the main pitfalls in this approach for developers used to the Java ecosystem?
You are using a Linux operating system to develop an extension for Excel, which is primarily Windows. The Mono Platform is pretty excellent - but you could run into bugs - either with C# or F#. It's not as big of an issue as it was a few years ago, but worth considering. If you do decide to stick on the Mono / Linux platform - MonoDevelop is the way to go.
Are there better alternatives to NAnt and NUnit for building and running automated tests, especially for F#?
Take a look at FsUnit if you plan on going with F#. It has some nice syntax assertions, etc. It's complimentary to NUnit, so you won't be in uncharted waters.
I am setting up the build system for a team that produces APIs used on several platforms and architectures. There has been a lot of work already spent on setting up Ant to build all of the Java code, so I would prefer to stick with Ant if possible.
Where I am stumped is how to build the C++ software. Here are the platforms and languages I need to support:
Java - Linux - 32bit & 64bit: Ant
Java - Windows - 32bit & 64bit: Ant
C++ - Linux - 32bit & 64bit: Ant w/CppTasks (question #1)
C++ - Windows - 32bit: (question #2)
Note: C++ on Windows is MS Visual Studio C++ projects.
I think the answer to question #1 is CppTasks because that seems to be the standard way to build C++ from Ant.
For question #2, I could also use CppTasks, but the developers will be compiling in Visual Studio, so it seems beneficial to use their Visual Studio project for building, which means calling MSBuild from Ant.
Has anyone tried this before and has a good solution for building Java & C++ on both Linux and Windows?
Do you use a Continuous Build System like Jenkins?
With Jenkins, your builds can be automatically triggered by check in/commit, time of day, and/or on command. The great thing about Jenkins is that you can have it automatically build all of the various versions of your software.
For example, you'll probably need to run make on Linux C++ but use msbuild on Windows systems, and you'll need to trigger a build on a Linux machine and one for a Windows machine. Jenkins can be setup to do this automatically. When a commit happens, all your various builds on all of your systems can be triggered at once. Then, you can store the builds you need on Jenkins and have your users actually pull the type they need off the project they need.
There are so many ways this could be setup, but the easiest is to simply create four separate jobs (One for Java 32bit, Java 64bit, C++ Linux, and C++ Microsoft). You don't necessarily need a separate Microsoft Java build (at least in theory), but there's nothing stopping you.
You can have a single Jenkins server run "slave" jobs on other build systems, so you could have Jenkins live on the 64Bit Linux system, but use a 32bit Linux system as a slave to do the 32bit build, and call a Windows slave to do the Visual Basic build. That way, all of your jobs are located in a central place, but you can use the environments you want.
If you've never used a Continuous Build system, download Jenkins and play around with it. It's free and open source, and very, very easy to use. You can run it on any machine that has a JDK or JRE 1.6. If you download the Windows version, it even comes with the JRE already built in.
Your best bet is to use a continuous build system and allow it to handle the mess. By the way, there's also Bamboo, CruiseControl, and Hudson (which was split from Jenkins a few months ago)
TeamCity should fit the bill very well. It supports Ant and MSBuild natively and has a pretty good cross plartform story (written in Java but excellent integration with e.g. Win).
Dont see any benefit in wrapping you Win MSBuild-based builds in yet another build system.
The list for this looks a little bit different (in my opinion)
Java -Maven for all platforms
C++ - Maybe Maven as well (Check http://duns.github.com/maven-nar-plugin/).