Problem with STB support about mlpack HOT 7 CLOSED

Thanks for you answer,

When I add message(STATUS "STB_IMAGE_FOUND is set and pre-processor flag HAS_STB has been added") after line 322, I correctly see it displayed when running cmake ... The mlpack CLI apps seems to be compiled correctly with the -DHAS_STB flag.

I'm not much familiar with cmake, so maybe I just don't understand what it is supposed to do, but I would expect the #define HAS_STB to be included by cmake in the mlpack headers installed in my /usr/local/include/mlpack folder, so that when I include mlpack in my c++ programs, the version that supports STB is loaded. For now, it doesn't seem the case. I managed however to make it work by manually adding the #define HAS_STB before the #include <mlpack.hpp> in the test program above.

Is that what we are supposed to do (defining HAS_STB manually in our programs before including mlpack) ?
If yes, I think the install instructions and the Image Utilities Tutorial should mention this. I guess another solution would be for cmake to add -DHAS_STB in the cflags of the pkg-config file it generates.

from mlpack.

Thanks for the report. This is actually a leftover from before mlpack changed to be a header-only library. You are right that the workaround for now is just to add -DHAS_STB to your compilation command, but you are also right that this should be automatically defined at install time whenever STB is detected.

It may be a couple days before I get to it, but I'll open a PR that handles this, likely by generating a file with HAS_STB set or unset based on what is found at configuration/build time.

(I'll also probably rename it MLPACK_USE_STB or similar, so it doesn't interfere with any other symbols. Originally, when mlpack was not header-only, the macro was only used inside of libmlpack.so and thus never needed to be encountered by the user. However, this was not properly adapted when mlpack was changed to be header-only, like I alluded to earlier.)

from mlpack.

I opened a fix in #3529. I think the description of the fix may be longer than the fix itself, but I'm not sure. The tl;dr is that mlpack's next release will have a file mlpack/config.hpp that automatically defines MLPACK_HAS_STB depending on whether STB was found when mlpack was configured and installed. (Also, the macro was renamed to avoid conflicts.)

Thank you for the report! This was a tricky thing to fix with lots of details, but I'm glad to have a solution on the way.

from mlpack.

Update: I also tried to install mlpack on a different computer, running Ubuntu 22.04 LTS. On this computer, the package libmlpack-dev is available but is a really old version (3.4.2), so I tried to compile mlpack using cmake --> make instead. I get the same error message as on my other computer, "mlpack was not compiled with STB support", even though cmake finds STB correctly.

from mlpack.

• Since you are building from source code, you can do some debugging to find any potential problems.
• The log message that you get is from "src/mlpack/core/data/load_image_impl.hpp" line 177 (at least in mlpack 4.2.0)
• The message gets printed when the pre-processor flag HAS_STB isn't set.
• This pre-processor flag is set in "CMakeLists.txt" line 322. You can add a line after line 322: message(STATUS "STB_IMAGE_FOUND is set and pre-processor flag HAS_STB has been added").
• Note that STB_IMAGE_FOUND is set during find_package(StbImage) which should be above that line in the same file.
• find_package will call "CMake/FindStbImage.cmake". You can put similar debug messages in this file to find any problems.

from mlpack.

Sounds good, thanks !

from mlpack.

Okay, with #3529 merged, I think that this issue is fixed. Feel free to try on the current master branch and report back if there are still issues, or wait until the next stable release (should be soon). Thanks again for the report!

from mlpack.