Hello,


I'm building a pair of companion oasis build spec and opam package setup
for a C library. libdai I figured out how to get swig and oasis to build
most things I need, but I'm having trouble getting oasis to not generate
_stubs targets that aren't found. There is a static C/++ libdai.a file that
is the product of the project I'm trying to wrap. I can't convince oasis to
use that instead. Here's my _oasis target:


Library "dai"
  Path:                 ./
  Install:              false
  Modules:              Swig, Dai
  CompiledObject:       best
  CSources:             dai_wrap.cxx.c
  CCOpt:                -g -xc++ "-I../../include"


With a fresh clone of libdai, I get dai_wrap.cxx.c by doing the following
in ./swig after building libdai:

$(SWIG) -ocaml -c++  dai.i
mv dai_wrap.cxx dai_wrap.cxx.c
sed -i -e 's/caml_array_length/caml_array_len/g' dai_wrap.cxx.c

I got my swig and dai ml files by doing the following:

swig2.0 -ocaml -co dai.ml
swig2.0 -ocaml -co swig.ml
swig2.0 -ocaml -co swig.mli

I build by doing the following:

ocaml setup.ml -configure
ocaml setup.ml -build


I get the following error:


Solver failed:
  Ocamlbuild knows of no rules that apply to a target named
./libdai_stubs.a. This can happen if you ask Ocamlbuild to build a target
with the wrong extension (e.g. .opt instead of .native) or if the source
files live in directories that have not been specified as include
directories.
Compilation unsuccessful after building 8 targets (8 cached) in 00:00:00.
E: Failure("Command ''/usr/bin/ocamlbuild' ./libdai_stubs.a
./dlldai_stubs.so ./dai.cma ./dai.cmxa ./dai.a ./dai.cmxs -j 5 -tag debug'
terminated with error code 6")

I want to make sure that the actual target shared library that was produced
by the libdai build file itself is linked against. But oasis is assuming I
have a _stubs target. I read in the documentation here that: "The usual
idiom is to append _stubs to the name."
https://ocaml.org/learn/tutorials/setting_up_with_oasis.html#Interfacing-with-C-code

And I think that that is the source of the error, but it isn't well
explained. The ultimate things I originally wanted was to be able to use
libdai with both the utop or the bytecode interpreter and with fully
compiled targets. I was going to make libdai a library and then publicize
it.

If anybody needs to replicate my issue, I have a docker container with this
already.