Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 18 2022 18:55
    sdegrande commented #233
  • Dec 18 2022 18:15
    sdegrande commented #233
  • Dec 18 2022 10:33
    rmorozov commented #233
  • Dec 18 2022 10:31
    rmorozov closed #233
  • Dec 18 2022 10:31
    rmorozov closed #234
  • Dec 17 2022 17:27
    rmorozov opened #234
  • Dec 15 2022 15:14
    sdegrande opened #233
  • Dec 12 2022 08:26
    rmorozov closed #219
  • Dec 12 2022 08:26
    rmorozov commented #219
  • Dec 12 2022 08:25
    rmorozov commented #222
  • Dec 12 2022 08:25
    sdegrande commented #230
  • Dec 12 2022 08:25
    rmorozov closed #222
  • Dec 12 2022 07:05
    rmorozov closed #231
  • Dec 11 2022 19:44
    rmorozov closed #230
  • Dec 11 2022 19:44
    rmorozov commented #230
  • Dec 11 2022 19:43
    rmorozov closed #223
  • Dec 11 2022 19:43
    rmorozov commented #223
  • Dec 11 2022 19:39
    rmorozov opened #231
  • Dec 11 2022 19:15
    rmorozov closed #226
  • Dec 11 2022 17:22
    rmorozov synchronize #226
Javier G. Sogo
@jgsogo
We've being thinking for long about where to put the recipes: with the code of the library or outside in a different repository, there are pros and cons for each approach
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
Javier G. Sogo
@jgsogo
The dreamed scenario would be to have recipes outside the repo (decoupled releases, more contributions from the community) but also inside (more visibility, help with the CI and also the Conan package could be the product of the release)
Talking about Jinja2Cpp, @Manu343726 I'm not sure if you have reviewed my PR :thought_balloon:
Flex Ferrum
@flexferrum
Good pros and cons. I'm considering the idea to put conan recipes to the separated repo inside Jinja2Cpp project. From the one side, recipes could be managed separately. From the other side, they are coupled with the project.
Javier G. Sogo
@jgsogo
What do you mean by Jinja2Cpp project?
Flex Ferrum
@flexferrum
Javier G. Sogo
@jgsogo
ok, I call it organization :+1:
Flex Ferrum
@flexferrum
Yep. :)
Flex Ferrum
@flexferrum
Any extra ideas? #123
Flex Ferrum
@flexferrum
Flex Ferrum
@flexferrum
@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
Flex Ferrum
@flexferrum
Some investigation shown what after clear clone of expected-lite repo tags aren't fetched.
@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.
Flex Ferrum
@flexferrum
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.
Flex Ferrum
@flexferrum
Meet the conan.io package for the Jinja2C++ 1.0.0!
Need to fix passing MSVC runtime type from conan settings to the Jinja2C++ cmake - and ready to upload the package to the bintray.
Flex Ferrum
@flexferrum
Javier G. Sogo
@jgsogo
We think it is the best way for open source projects and community (but I'm a little bit biased :laughing: )
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
Flex Ferrum
@flexferrum
So, I'll send the request for participate in EAP.
Thanks!
Do I understand correctly: when I make a PR to this repo, I won't need to maintain the recipe?
Javier G. Sogo
@jgsogo
Anyone will be able to submit a new PR to fix/improve, add new versions of your library,... it decouples recipe development from the library (or viceversa)
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
Flex Ferrum
@flexferrum
Thanks for the explanation!
Martin Moene
@martinmoene

@flexferrum (msg Aug 7) Are the tags still missing on a fresh clone? I get:

>git tag
v0.1.0
v0.2.0
v0.3.0

Original local repo also has v0.0.0, v0.0.1

Sorry for taking this long to come back at this.

Flex Ferrum
@flexferrum
Sorry for taking this long to come back at this.
No problems. :)

Are the tags still missing on a fresh clone

No. Now everything is fine.

Martin Moene
@martinmoene
Ah , just doing nothing can solve some things :)
Flex Ferrum
@flexferrum
Yes. Definitely. :)
Javier G. Sogo
@jgsogo
Great! I'm not sure if today (weekend) we will be able to move it, it depends on people taking care of the infrastructure too, and we try to rest a little bit out of work hours
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
Flex Ferrum
@flexferrum

Thanks!

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

Actually, it's possible to get rid of this deps as a conan deps and take it from github directly.

Flex Ferrum
@flexferrum
@jgsogo what do you think: in case of Jinja2Cpp what is better: to push @martinmoene recipes to the conan or to make them as a non-conan dependencies? I'd prefer the second case, but I need extra opinion.
Javier G. Sogo
@jgsogo
I think that @martinmoene recipes should be in Conan-center, for sure. You can always hide them behind your interface and it won't be a problem for people consuming your package. But if your API exposes some of the nonstd headers and your consumers are using a different version, the may have some problems
btw, you two are added to the EAP of Conan-center, you can submit the recipes and the CI will run ^^
Martin Moene
@martinmoene
I'd like to provide these recipes, but I may need some help with them... These weeks my mind is in a totally different place, of which the most earthly one is a kitchen-redo :)
Flex Ferrum
@flexferrum
Yes, I expose nonstd types via public interface. So... If @martinmoene doesn't mind, I'll submit the PR with his libraries I use.