I’d like to set up jbuilder in such a way that when I run jbuilder runtest it only builds the host/native target and for jbuilder build it reads targets in jbuild-workspace. Is it currently possible?
For now I’ve removed jbuild-workspace altogether and I build for cross compilation with the -x flag.
I’m not exactly sure what you’re asking for. The runtest alias is for building & running the tests. How do you plan to run any tests on the target platform?
That’s my point - I cannot run tests for let’s say windows target when I’m on a mac host. What’s more, test dependencies might not be available for other platforms than the host. Because of that I’d like jbuilder runtest to only build for the native target. Currently if I have (targets (native windows)) and I run runtest it also tries to build windows.
OK I think I understand. Let’s remember and be clear about the runtest alias building and running the tests. So we can build the tests for all targets, but what you’d like to restrict the running to only the host.
I’d like to restrict both running and building to the host. To make the example concrete: I use alcotest as my test dependency and since there’s no alcotest from opam-cross-* installed, the build of test executable fails for an x compilation target. I’m sorry if it’s confusing.
How about just renaming your workspace file to something like jbuild-workspace.x and only using it for cross compilation using --workspace. Then you can run the tests without a workspace file at all (or perhaps a different workspace file)
I see, thank you. Currently I achieve a similar thing if I use the -x flag. Shouldn’t jbuilder runtest build host only by default?
@rgrinberg Reading this discussion got me a bit confused it seems that jbuilder is not using autoconf/automake's terminology. I think it would be better if it did. See here and here. Basically it seems you are using host/target for what should be build/host.
That’s a good point and still possible because we haven’t yet released the cross compilation feature. @jeremiedimino what do you think about the terminology change?
I’m all for using standard terminology, but how standard is it? If I look at the clang documentation for cross compilation, it talks about host/target in the same way as jbuilder currently does for instance.
Well if OCaml switches to autotools which AFAIK was the plan it will get needlessly confusing.
Maybe clang can’t do a canadian cross but you really need three distinguished systems when you are talking about compiling compilers.
Note that if you read ocaml's current notion of host/target in the install file they do have autotools's semantics. That is host is where the produced binaries are run.
AFAIU, clang can always generate code for all platforms, and you just just select the target at runtime with clang -target blah, so you don’t need the triplet when compiling clang itself.
I looked at a few other projects (go, mxe, …) and it seems to me that “target” always means the platform you are compiling for.
In autotools terms, I don’t understand why jbuilder needs to know about the target. It needs to know about build and host in order to perform the build, but it seems to me that you could do build a cross-compiler with jbuilder that would run on another machine without jbuilder knowing what target means.
@wokalski, you should be able to build & run the tests for the host only by doing:
$ jbuilder runtest _build/default
Yes that’s correct, build systems only need to know about the build/host distinction.