Git Product home page Git Product logo

Comments (4)

memsharded avatar memsharded commented on June 23, 2024 1

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.

from conan.

Drllap avatar Drllap commented on June 23, 2024

@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 😆
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
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

from conan.

memsharded avatar memsharded commented on June 23, 2024

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.

from conan.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.