[question] Info on best way to debug/develop packages

[Drllap]

Hi I have just spent an embarrassingly long time debugging an error I was having when creating a conan packet for a shared library. My starting point was conan new cmake_lib -d name=hello -d version=1.0 and what turned out to be my issue was that I was missing the export definitions for some of the public API of the lib, this thing from the hello example:

#ifdef _WIN32
  #define HELLO_EXPORT __declspec(dllexport)
#else
  #define HELLO_EXPORT
#endif

Now the only way I know how to "debug" this kind of issue is basically by trial and error, running conan create . between trying to change things. The thing is that the error message doesn't help a lot:

-- Conan: Target declared 'hello::hello'
CMake Error at build/msvc-194-x86-debug/generators/cmakedeps_macros.cmake:67 (message):
  Library 'hello' not found in package.  If 'hello' is a system library,
  declare it with 'cpp_info.system_libs' property
Call Stack (most recent call first):
  build/msvc-194-x86-debug/generators/hello-Target-debug.cmake:23 (conan_package_library_targets)
  build/msvc-194-x86-debug/generators/helloTargets.cmake:24 (include)
  build/msvc-194-x86-debug/generators/hello-config.cmake:16 (include)
  CMakeLists.txt:4 (find_package)

Basically, there is something bad happening in conan_package_library_targets, and I can't add message or something there to figure out what because this file is regenerated every time. Also, using conan create . for trial and error for this is very annoying because it compiles the library every time, but it is the test_package step that is failing.

My question I guess, is there a page with Tips & Tricks for package developers or some other resources that anyone can point me towards?

Thanks in advance and sorry for the semi-rant

PS: I'm using Conan version 2.4.1

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @Drllap

Thanks for your question

Now the only way I know how to "debug" this kind of issue is basically by trial and error, running conan create . between trying to change things.

I think this could be the thing to avoid. conan create is a package creation process, it is not intended as a "development" flow, but mostly as a package/ci flow. It shouldn't be the place where these kind of issues are detected and debugged, because for example, the conan create builds from scratch every time, making it quite slow. It also build things in the cache, making it not very convenient to debug.

The recommended flow would be to use the local flow. Using conan build . triggers the installation of dependencies plus a local execution of the build() method. This has some advantages:

• All the artifacts are local in your user folder, easier to inspect
• Builds can be incremental
• It is not even necessary to do conan build . after the first time, but using cmake .. or opening in the IDE can be done
• The build() method can contain for example a cmake.ctest() execution that run unittests. These tests should be able to capture early some issues. The execution of tests in build() in default helpers is inhibited by the tools.build:skip_test, but if you want to run extra checks you can use that conf to protect them (and not run them every time, just when you want)

So mostly, removing Conan as much as possible from the normal development flow. Conan 2 did a great effort with the layout(), generate() and the transparent integrations such as CMakeToolchain and CMakeDeps, to be able to use pretty much standard cmake for example, in that sense, this wouldn't be the debug of a Conan package, it would be just the debug of a regular CMake project creating a shared library. That should make the debugging much easier.

You can read more about this in the tutorial: https://docs.conan.io/2/tutorial/developing_packages.html

Please let me know if this helps.

[Drllap]

@memsharded Thx for the response

The conan build . seems very useful, but after trying it out it doesn't look like it triggers the test_package step. I'm now trying this "editable mode", and if I get it to work I would think it is a game-changer :satisfied: To simulate the problems I have been facing today I have done the following:

• Create a new hello packet: conan2 new cmake_lib -d name=hello -d version=1.0
• Change the

  #ifdef _WIN32
  #define HELLO_EXPORT __declspec(dllexport)
  #else
  #define HELLO_EXPORT
  #endif

  to just

  #define HELLO_EXPORT

  in include\hello.h and change the default_options = {"shared": True} in conanfile.py

• I run conan2 build . everything executes without errors
• I run conan2 create . but hat fails with the cryptic error in the description.
• I follow the "Packages in editable mode" page you linked and do the following:

  conan2 editable add .
  conan2 install . -s build_type=Debug
  cmake --preset conan-default
  cmake --build --preset conan-debug

• I cd to the test_package folder because that's where the issue is, as in it is the "user" from this: https://docs.conan.io/2/tutorial/developing_packages/editable_packages.html#using-say-1-0-package-in-editable-mode
• I run conan2 install . -s build_type=Debug and it finishes successfully

• But when I run cmake --preset conan-default I get:

  CMake Error at CMakeLists.txt:4 (find_package):
  Could not find a package configuration file provided by "hello" with any of
  the following names:
  
  helloConfig.cmake
  hello-config.cmake
  
  Add the installation prefix of "hello" to CMAKE_PREFIX_PATH or set
  "hello_DIR" to a directory containing one of the above files.  If "hello"
  provides a separate development package or SDK, be sure it has been
  installed.

  And looking in the dir there are no .cmake files in it after the conan install command as I would expect

[memsharded]

The conan build . seems very useful, but after trying it out it doesn't look like it triggers the test_package step.

Because the test_package is designed to test that the package has been correctly created, that is, that the headers and the libraries have been copied to the final package folder, etc. It is not designed to test the functionality or correctness of the library itself, that belongs to the "build" step, and the build() method should be enough to guarantee that the built artifacts are correct, via unit-testing and the like.

In any case, you might still try to have the best of both worlds, if you put the package in editable mode with conan editable add ., the conan create . will both build locally, not in the cache (like conan build .) and the test_package will be run. The condition is that the layout must be correct and specially must correctly define the development local layout via self.cpp.source and self.cpp.build.

I run conan2 build . everything executes without errors

the problem is that the default conan new template is not that complete to test the correctness of the artifacts given that the code is being changed. For correctness it should include some unit testing and adding something like cmake.ctest() to the recipe, to catch the errors in the conan build . step.

I cd to the test_package folder because that's where the issue is, as in it is the "user" from this:

It should never be necessary to cd to the test_package folder and execute local conan commands there. The test_package is designed to be executed automatically by Conan, and if it is intended to be run in isolation, then with conan test command, but not with conan install commands inside the folders. When you are doing this conan install, the test_package detects NO dependencies, it doesn't depend on the "hello" package, because that is injected dynamically when the test_package is automatically executed by Conan.

To summarize:

• Best approach IMO would be to add some minimal testing in the build() method via cmake.ctest() or the like to guarantee correct functional behavior
• A secondary approach to consider, most likely on top of the previous one with the build()+unittests would be to put the package in editable mode and do just conan create . locally, it will run the test_package against the local build.

Please let me know if this helps.

[Drllap]

Thanks that clears things up quite a bit