Building OpenCV is failed when describing evision in deps of mix.exs of a new mix project

[cocoa-xu]

Building OpenCV is failed when describing evision in deps of mix.exs of a new mix project

[zacky1972]

Great! It has been solved by the following command you taught:

cp -a deps/evision/config config

Thank you a lot.

[zacky1972]

Excuse me,

I tested a new mix project importing nx_evision, which imports evision.
Then, the error occurs, again.

That is, we must do the setting of config.exs for each such nested importing.

I felt this is very troublesome. How do you think?

[cocoa-xu]

I understand what you mean while I was trying to reproduce the error you described.

Elixir projects are organised in the form of a, well, project, and the top-level project has control over all its dependencies. Although we can set evision as a dependency of nx_evision while using both nx_evision and evision as dependencies in the top-level project, that can cause some confusion. For example,

if you want to test nx_evision as a standalone project, you'll need evision configured in nx_evision/config. However, when you set both nx_evision and evision as the dependencies of another top-level project, then that top-level project will be in charge of providing the configuration for all its dependencies (including sub-dependencies).

Therefore, in Elixir, you do have to have duplicated configuration files. But only the ones that are in the top-level project's config directory are effective.

---

I think it should be enough if the config.exs is in the top-level project. I tried the following commands,

mix new top_level
cd top_level

edit the mix.exs

defmodule TopLevel.MixProject do
  use Mix.Project

  def project do
    [
      app: :top_level,
      version: "0.1.0",
      elixir: "~> 1.13",
      start_permanent: Mix.env() == :prod,
      deps: deps()
    ]
  end

  def application do
    [
      extra_applications: [:logger]
    ]
  end

  defp deps do
    [
        {:nx_evison, github: "zeam-vm/nx_evision"},
        {:evision, "~> 0.1.0-dev", github: "cocoa-xu/evision", branch: "main"}
    ]
  end
end

mix deps.get
cp -a deps/evision/config ./config
mix compile

[cocoa-xu]

I can reproduce this error on my mac as well. And actually, it was caused by linking to the zlib library.

...
--   Media I/O:
--     ZLib:                        zlib (ver 1.2.11)
--     JPEG:                        build-libjpeg-turbo (ver 2.1.2-62)
--     WEBP:                        build (ver encoder: 0x020f)
--     PNG:                         build (ver 1.6.37)
--     TIFF:                        build (ver 42 - 4.2.0)
--     JPEG 2000:                   build (ver 2.4.0)
--     OpenEXR:                     OpenEXR::OpenEXR (ver 3.1.3)
--     HDR:                         YES
--     SUNRASTER:                   YES
--     PXM:                         YES
--     PFM:                         YES
...
make[3]: *** No rule to make target `zlib', needed by `lib/libopencv_imgcodecs.4.5.5.dylib'.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....

However, if you cd to the deps/evision and run

mix deps.get
mix compile

It will work as expected (and the zlib will be built using the bundled version).

--   Media I/O:
--     ZLib:                        build (ver 1.2.11)
--     JPEG:                        build-libjpeg-turbo (ver 2.1.2-62)
--     WEBP:                        build (ver encoder: 0x020f)
--     PNG:                         build (ver 1.6.37)
--     TIFF:                        build (ver 42 - 4.2.0)
--     JPEG 2000:                   build (ver 2.4.0)
--     OpenEXR:                     build (ver 2.3.0)
--     HDR:                         YES
--     SUNRASTER:                   YES
--     PXM:                         YES
--     PFM:                         YES

I suspect that some environment variables may be changed when using it as a dependency... I'll look into this.

[cocoa-xu]

Oh, I see. Is this an issue? Yes and no.

The No Part (the solution)

It's just that you need to copy or merge the config from evision to the top-level project.

If you don't have any other config in the top-level project, then you can just copy the whole config directory

cp -a deps/evision/config config

Otherwise, you can import this config file at the end of existing config/config.exs

cp -a deps/evision/config/config.exs config/evision.exs
echo 'import_config "evision.exs"' >> config/config.exs

And then it should work.

mix compile

@zacky1972 the above solution should be able to solve this issue :)

The reason is that if there is no corresponding config file in the top-level project, Application.get_env(:evision, :enabled_modules, []) will return []. And it further causes the CMAKE_OPTIONS passed to the Makefile to be empty, that's why we see the OpenCV wants to link to the zlib on your system instead of building it.

The Yes Part (possible improvement, feel free to ignore this)

Perhaps I need to set some default values for this. Although in that way, we cannot let OpenCV's CMake file decide which modules can be enabled on the user's system.

  defp get_config(false) do
    enabled_modules = Application.get_env(:evision, :enabled_modules, [])
    disabled_modules = Application.get_env(:evision, :disabled_modules, [])
    enabled_img_codecs = Application.get_env(:evision, :enabled_img_codecs, [])
    compile_mode = Application.get_env(:evision, :compile_mode, "auto")
    {enabled_modules, disabled_modules, enabled_img_codecs, compile_mode}
  end

Furthermore, some issues in the Makefile contributed to this problem.

[cocoa-xu]

One of the trade-offs that I can think of is: as long as you have the desired configuration for a certain library in the top-level project, you don't need to worry about whether one of your dependencies configures that library with parameters you don't want.

[zacky1972]

I see. Then, I'll revise README of nx_evision to write the dependencies. Thanks.

[cocoa-xu]

I received another issue #41 and it was basically the same problem here. I pushed a fix (5e8d1b5) for it.

In simple words, 5e8d1b5 makes it more like what we would expect, or how CMake handles default configuration for projects.

In that fix, the default config (config/config.exs in this project) will always be loaded. If the user does not set the corresponding evision config file or some configuration parameters are missing in the top-level project, the values loaded from deps/evision/config/config.exs will be used.

[cocoa-xu]

The fix should be good for most users and cases. But it's worth noting that the default configuration will build everything that evision supports in OpenCV. This will increase the build time and the footprint of the library.

I'll close this issue for now, but please feel free to reopen/link to it if relevant errors happen in the future!