Re: [Caml-list] oasis and C wrapper

[Kenneth Adam Miller <kennethadammiller@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6020 bytes --]

Ok I think I found the source of the error - this was in the _build/_log:

### Starting build.
Backtrace:
                      - Failed to build the target libdai_stubs.a
                          - Building libdai_stubs.a:
                              - Failed to build all of these:
                                  - Building libdai_stubs.cmx:
                                      - Failed to build all of these:
                                          - Building libdai_stubs.ml:
                                              - Failed to build all of
these:
                                                  - Building
libdai_stubs.mly
                                                  - Building
libdai_stubs.mll
                                          - Building libdai_stubs.mlpack
                                  - Building libdai_stubs.mllib
                                  - Building libdai_stubs.clib
# Compilation unsuccessful.

The problem is that libdai_stubs.a is already built, and ocamlbuild is
trying to build it again! Also, I followed the with-c oasis example to a T,
and theirs never tried to build .cmx/mllib/mlpack/mly/mli suffixed
auto-generated C source file targets. So why would it try and do that with
mine?? I found that changing the library name of mine in my _oasis causes
oasis/ocamlbuild to search for an appropriately named .ml file. But that
doesn't happen in the with-c example, and not only that, the with-c example
doesn't have a with-c.ml file anyway?! Also my issue has been replicated in
two different dockers, stale mated on a Mac, and then also within an ubuntu
vm.

I can't make this opam package until I get oasis and ocamlbuild to work
together.

On Sun, Aug 27, 2017 at 3:56 PM, Kenneth Adam Miller <
kennethadammiller@gmail.com> wrote:

> Ok, so I got the with-c example to build by running -configure before I
> built with ocaml setup.ml -build, and that worked. But then there's a
> part in there where ocamlbuild is passed a libwith-c_stubs.a target and it
> knows what to do with it. I've tried to copy that example line by line in
> my _oasis and command line steps, and I have know what calls ocamlbuild
> should be making to get the .cma and .cmxa targets. But I can't get my
> _oasis to work.
>
> On Sun, Aug 27, 2017 at 1:19 AM, Kenneth Adam Miller <
> kennethadammiller@gmail.com> wrote:
>
>> Actually, I think it's that ocamlbuild should be told to link
>> libdai_stubs.a, and not try and build it. But also, I wanted to reference
>> an existing work that links with C libraries, and I found ocamlbuild's
>> example, with-c. I tried to build it, and I found that it isn't built by
>> the harness default. Also, if you just try and build within just that raw
>> directory in isolation, that it fails with a similar error I had been
>> getting earlier. I looked around and found these:
>>
>> https://stackoverflow.com/questions/19644451/how-to-make-
>> ocamlbuild-compile-and-link-a-c-file-into-an-ocaml-project
>> https://l-lang.blogspot.com/2012/08/incorporating-c-code-in-
>> ocaml-project.html
>> https://ocaml.org/learn/tutorials/ocamlbuild/Using_an_extern
>> al_library.html
>>
>> And I'm trying to follow, but they each give unique directions, each seem
>> to not work for me.
>>
>> On Sat, Aug 26, 2017 at 9:12 PM, Kenneth Adam Miller <
>> kennethadammiller@gmail.com> wrote:
>>
>>> 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.
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 9150 bytes --]