If the recipe is in the same repo, we as Conan gain visibility, you have a
conanfile.py file there and people will get interested, also you may use Conan for your CI and the Conan package could be the resulting artifact of your release.
This approach is nice, the library author won't release a new version if something is broken in the Conan recipe. But many times we find bugs in the recipe, or people is using a different compiiler or some combination of settings and options don't work... and you need to modify the recipe. In this situation you would need to release a new version if the recipe is part of the sources
Having recipes in a different folder make it posible to decouple the release cycle of the library from the release cycle of the recipe itself. And we think that it is also better for the community, as there are more contributions to recipes and it can evolve faster
Talking about Jinja2Cpp, @Manu343726 I'm not sure if you have reviewed my PR :thought_balloon:
@Manu343726 , look at this interesting message:
expected-lite/0.2.0@Manu343726/testing: Configuring sources in C:\Users\appveyor\.conan\data\expected-lite\0.2.0\Manu343726\testing\source
expected-lite/0.2.0@Manu343726/testing: Getting sources from url: 'https://github.com/martinmoene/expected-lite'
ERROR: Command 'git -c http.sslVerify=false checkout "v0.2.0"' returned non-zero exit status 1
error: pathspec 'v0.2.0' did not match any file(s) known to git.
I've got it during the test build with conan version of Jinja2Cpp
@martinmoene why can it happen?
I cloned
optional-lite did git tag and got list of tags.
I did the same with
expected-lite and got empty list
Actually, Manu's
expected-lite conan package now broken due to this issue. And I suppose Martin's conan package is broken as well for the same reason.
And one more question. Jinja2C++ got one dependence which is absent in conan (robin_hood hash map). Thus conan build script should relay not only conan deps, but on external repo. How to implement in correctly? Can I treat this dep as internal and get it from github inside my build scripts or there is more convenient solution.
Need to fix passing MSVC runtime type from conan settings to the Jinja2C++ cmake - and ready to upload the package to the bintray.
I think, that's good opportunity for Jinja2Cpp https://blog.conan.io/2019/09/04/A-new-binary-building-service-for-Conan-center-packages.html
Community will help you to maintain the recipe and we will be able to generate the packages if a new compiler appears
Also, you don't have to worry about writing your CI for Conan
Thanks!
Do I understand correctly: when I make a PR to this repo, I won't need to maintain the recipe?
the community can take care of the recipe. Although someone (us) has to approve the PR, we free the library author from that burden
If you apply for the EAP, I will ensure that you are included asap
No problems. :)
Are the tags still missing on a fresh clone
No. Now everything is fine.
Your recipe depends on @martinmoene ones. Anyone can make the PR with a recipe, of course, but in case of recipe-library authors we (Conan team) prefer to wait and give them the opportunity to try Conan-center on their own... unless they ask for help