OMake backend passes OCAMLCFLAGS and OCAMLOPTFLAGS to gcc

[ivg]

From the documentation

OCAMLCFLAGS flags to pass to "ocamlc" OCAMLOPTFLAGS flags to pass to "ocamlopt" OCAMLFLAGS flags to pass to "ocamlc" and "ocamlopt"

However, in oasis_lib.om

        if $(gt $(length $(OCAMLCFLAGS)), 0)
            byteflags = -ccopt $(quote $(OCAMLCFLAGS))
            export byteflags
        if $(gt $(length $(OCAMLOPTFLAGS)), 0)
            natflags = -ccopt $(quote $(OCAMLOPTFLAGS))
            export natflags

Passes them to gcc via the -ccopt. In best case, this leads to compilation erros from gcc, but sometimes it is even worse, e.g.,

OCAMLOPTFLAGS += -opaque

leads to the following command run underneath the hood

gcc -shared -o 'disasm.cmxs'   '-L/home/ivg/.opam/dev/lib/ocaml' -opaque 'disasm.cmxs.startup.o' 'disasm.a'  '-L.'

And gcc interprets -opaque as -o paque and outputs code into paque file instead of disasm.cmxs :)

Workaround

The OCAMLFLAGS option works fine and passes flags only to ocamlc and ocamlopt. However, it won't work if you need to pass options different to bytecode or native compiler, cf. NativeOpt and ByteOpt fields of the oasis specification.

[ivg]

I've pushed a few PRs that cover all my issues except this one and #135. I can provide fixes for these two also if you're interested. So far, the weren't in the critical path for us. Please, poke me if you want it to be fixed :)

As a user story. In BAP we enabled omake as an alternative compilation backend (for the development) mode. Modulo bugs in the oasis backend, it went smooth (that's surprising given that we have a lot of setup.ml.in and ocamlbuild.ml.in code). The results surpassed our expectations, we switched from 30 minutes of compilation time to 2-3 minutes from scratch and to seconds and even milliseconds for recompilation. We've been using it internally since the beginning of the year and quite happy :) There is one (or maybe two) more issues, that we experience, but didn't report as they are hard to catch. Occasionally, during the recompilation, we get a syntax error (or undefined variable error) in setup_log.om, which is easily fixed by deleting this file (it is then recreated). I suspect, that this is some sort of a race condition. But this happens rather rarely, so it doesn't bother us a lot.

[gildor478]

Thanks for the user feedback. I am not an OMake user, so I let you choose if/when you want to have the remaining issues fixed.

Le mar. 28 janv. 2020 à 15:55, Ivan Gotovchits notifications@github.com a écrit :

I've pushed a few PRs that cover all my issues except this one and #135 https://github.com/ocaml/oasis/issues/135. I can provide fixes for these two also if you're interested. So far, the weren't in the critical path for us. Please, poke me if you want it to be fixed :)

As a user story. In BAP we enabled omake as an alternative compilation backend (for the development) mode. Modulo bugs in the oasis backend, it went smooth (that's surprising given that we have a lot of setup.ml.in and ocamlbuild.ml.in code). The results surpassed our expectations, we switched from 30 minutes of compilation time to 2-3 minutes from scratch and to seconds and even milliseconds for recompilation. We've been using it internally since the beginning of the year and quite happy :) There is one (or maybe two) more issues, that we experience, but didn't report as they are hard to catch. Occasionally, during the recompilation, we get a syntax error (or undefined variable error) in setup_log.om, which is easily fixed by deleting this file (it is then recreated). I suspect, that this is some sort of a race condition. But this happens rather rarely, so it doesn't bother us a lot.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ocaml/oasis/issues/133?email_source=notifications&email_token=AADORPLNCKJWUPVQ3DDV2CTRABBNXA5CNFSM4J2QMBJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKDSY6Q#issuecomment-579284090, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADORPOMFMYJRBG3AYDJEODRABBNXANCNFSM4J2QMBJQ .